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Abstract 


Practical  scheduling  problems  generally  require  allocation  of  resources  in  the  presence  of  a  large, 
diverse  and  typically  conflicting  set  of  constraints  and  optimisation  criteria.  The  instruct  tiredness  of  both 
the  solution  space  and  the  desired  objectives  make  scheduling  problems  difficult  to  formalize  This  paper 
describes  a  case-based  learning  method  for  acquiring  context-dependent  user  optimization  preferences 
and  tradeoffs  and  using  them  to  incrementally  improve  schedule  quality  in  predictive  scheduling  and 
reactive  schedule  management  in  response  to  unexpected  execution  events.  The  approach,  implemented 
in  the  CABIN'S  system,  uses  acquired  user  preferences  to  dynamically  modify  search  control  to  guide 
schedule  improvement.  During  iterative  repair,  cases  arc  exploited  for:  (l)  repair  action  selection,  (2) 
evaluation  of  intermediate  repair  results  and  (3)  recovery  from  revision  failures  The  method  allows  the 
system  to  dynamically  switch  between  repair  heuristic  actions,  each  of  which  operates  with  respect  to 
a  particular  local  view  of  the  problem  and  offers  selective  repair  advantages.  Application  of  a  repair 
action  tunes  the  search  procedure  to  the  characteristics  of  the  local  repair  problem.  This  is  achieved  by 
dynamic  modification  of  the  search  control  bias.  There  is  no  a  priori  characterization  of  the  amount  of 
modification  that  may  be  required  by  repair  actions.  However,  initial  experimental  results  show  that  the 
approach  is  able  to  (a)  capture  and  effectively  utilize  user  scheduling  preferences  that  were  not  present 
in  the  scheduling  model,  (b)  produce  schedules  with  high  quality,  without  unduly  sacrificing  efficiency  in 
predictive  schedule  generation  and  reactive  response  to  unpredictable  execution  events  along  a  variety 
of  criteria  that  have  been  recognized  as  important  in  real  operating  environments. 


ill 
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1.  Introduction 


The  scheduling  task  can  be  described  as  assigning  a  limited  number  of  resources  to  activities  over  time  in  a 
consistent  manner,  i.e.  so  as  to  avoid  violation  of  constraints  associated  with  the  problem,  such  at  resource 
capacity  constraints,  activity  precedence  constraints  and  release  dates.  The  goal  of  a  scheduling  system  is  to 
produce  schedules  that  respect  these  problem  constraints  and  optimize  a  set  of  objectives,  such  as  minimise 
tardiness  of  jobs,  minimize  work  in  process  inventory  (W1P),  maximize  resource  utilization,  minimize  cycle 
time  etc.  The  produced  schedule  should  also  respect  user  preferences.  Scheduling  is  difficult  to  automate 
for  the  following  reasons: 

1.  Computational  Complexity 

Scheduling  is  a  problem  in  the  "hardest”  subset  of  MP-complete  problems  [Fre82], 

2.  Tight  Constraint  Interactions 

Due  to  the  tight  interactions  among  scheduling  constraints  and  the  non-linear  nature  of  scheduling 
objectives,  there  is  no  general  way  to  predict  the  effect  of  a  local  optimization  decision  on  global 
optimality,  even  for  the  simplest  objective, 

3.  Ill-structured  Objectives  /  Preferences 

For  practical  scheduling  problems,  it  is  desirable  that  multiple  optimization  objectives  (e  g.  minimize 
weighted  tardiness,  minimize  work  in  process  inventory,  maximize  resource  utilisation)  must  be  sat¬ 
isfied.  Moreover,  optimization  objectives  often  interact  and  conflict  with  one  another.  To  optimize 
along  one  objective  alone  could  jeopardize  optimality  along  other  objectives.  The  relationships  between 
global  objectives  are  extremely  difficult  to  model 

The  definition/evaluation  itself  of  what  is  a  "high  quality”  schedule  is  fraught  with  difficulties  because 
of  the  need  to  balance  conflicting  objectives  and  tradeoffs  among  them.  Such  tradeoffs  typically 
reflect  the  presence  of  context-dependent  user  preferences  and  domain  constraints  not  captured  in  the 
scheduling  model.  The  value  of  incorporating  such  user  preferences  and  constraints  in  operational 
scheduling  environments  is  becoming  increasingly  recognized  (e.g  [MBS88])  but  good  techniques  are 
currently  lacking. 

4.  Dynamic  Environment 

Operational  environments  for  scheduling  systems  (e.g.  factories)  ate  dynamic  Unpredictable  events, 
such  as  machine  breakdown  or  operator  absence,  often  happen  during  schedule  execution.  Therefore, 
a  schedule  that  is  only  predictive  (i.e  it  is  created  assuming  that  the  world  is  static  and  predictable) 
will  be  brittle.  It  is  clear  that  any  effective  scheduling  system  should  be  reactive,  i.e.  perform  schedule 
revision  in  response  to  unforeseen  events  during  schedule  execution. 

The  scheduling  problem  has  been  addressed  by  two  general  types  of  methods,  constructive  scheduling 
and  revtsnm-iaserf  scheduling.  In  constructive  approaches  (e  g.,  [Fox63,  Sadfll]),  a  schedule  is  constructed 
by  incremental  construction  and  merging  of  partial  schedules.  In  revision- based  approaches  (e  g  ,  [MJPL90, 
ZDG90,  BC91,  LAL92J)  a  complete  but  suboptimal  initial  schedule  is  incrementally  repaired  by  several 
techniques,  such  as  a  min-conflict  heuristic  [MJPL90]  or  simulated  annealing.  In  [OST88],  wh'le  predictive 
schedules  are  generated  from  scratch,  incremental  revision  has  been  used  to  repair  a  pre-computed  schedule 
in  response  to  unanticipated  events  during  schedule  execution.  The  approach  analyzes  the  implications  of 
specific  schedule  features  and  matches  them  to  behavioral  characteristics  of  appropriate  reactive  actions  that 
are  selected  according  to  a  static,  pre-determined  control  model  These  approaches  assume  the  existence  of  an 
explicit  optimization  function  This  assumption  is  in  genera!  limiting  since,  in  practice,  optimization  criteria 
reflect  context-dependent  user  preferences  and  cannot  be  expressed  in  terms  of  a  single  global  objective 
function. 

In  this  paper,  we  describe  a  revision-based  approach,  implemented  in  the  CABINS  system,  that  provides 
a  unified  framework  for  acquisition  of  user  optimization  preferences  and  tradeoffs,  improvement  of  schedule 
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quality  based  on  these  preferences,  and  reactive  schedule  management  in  response  to  unforeseen  events. 
Unlike  other  systems  that  utilize  iterative  repair  to  find  a  feasible  solution  (e.g  (ZDG90,  MJPL90]),  where 
executability  of  the  schedule  was  not  guaranteed  at  the  end  of  each  repair  iteration,  CABINS  produces  an 
executable  schedule  after  each  repair  that  has  guaranteed  monotonic  increase  in  quality  the  more  time  it 
is  allowed  for  repair,  thus  exhibiting  anytime  eiecntahlc  behavior  [DB88).  This  is  a  very  desirable  quality 
especially  in  reactive  contexts  since  there  could  only  be  a  certain  limited  amount  of  time  for  the  system  to 
react. 

Our  approach  uses  integration  of  Case-based  Reasoning  (CBR)  [KSS85]  and  line  granularity  constraint- 
directed  scheduling  mechanisms  based  on  [SF90].  Integrating  CBR  with  constraint-based  scheduling  stems 
from  a  variety  of  motivations.  Although  scheduling  is  an  ill-structured  domain,  we  assume  that  it  exhibits  do¬ 
main  regularities  that  could  be  captured,  albeit  only  approximately,  in  a  ease  In  CABINS,  a  case  represents 
application  of  a  revision  action  to  one  activity  in  the  schedule,  thus  expressing  dependencies  among  features 
of  the  schedule,  the  repair  context  and  a  suitable  repair  action  (see  section  4.1  for  a  detailed  description  of 
case  representation).  CBR  allows  capture  and  re-use  of  this  dependency  knowledge  to  dynamically  adapt 
the  search  procedure  and  differentially  bias  scheduling  decisions  in  future  similar  situations.  On  the  other 
hand,  because  of  the  tightly  coupled  nature  of  scheduling  decisions,  a  revision  in  one  part  of  the  schedule 
may  cause  constraint  violations  in  other  parts.  Therefore,  constraint  propagation  techniques  are  necessary 
to  determine  the  ripple  effects  that  spread  conflicts  to  other  parts  of  the  schedule  as  case-based  repair  actions 
are  applied  and  specific  schedule  revisions  are  made.  The  evaluation  criteria  for  judging  the  acceptability  of 
the  outcome  of  a  repair  action  are  often  multiple,  conflicting,  context  dependent  and  reflect  user  judgment  of 
tradeoffs  Therefore,  it  is  difficult  to  describe  the  evaluation  criteria  and  the  associated  tradeoffs  in  a  simple 
manner.  The  case  base  incorporates  a  distribution  of  examples  that  collectively  and  implicitly  capture  a 
user’s  schedule  evaluation  preferences  and  tradeoffs  under  diverse  problem  solving  circumstances  and  enable 
CABINS  to  induce  these  tradeoffs  from  the  case  base.  Hence,  user  preferences  arc  reflected  in  the  esse  base 
in  two  ways:  as  preferences  for  selecting  a  repair  action  depending  on  the  features  of  the  repair  context,  and 
as  eiatuatwn  preferences  for  the  repair  outcome  that  resulted  from  selection  and  application  of  a  specific 
repair  action. 

A  revision-based  approach  is  attractive  for  solving  practical  scheduling  problems.  There  are  no  known 
efficient  search  algorithms  for  schedule  optimization  except  for  a  very  limited  set  of  simple  objectives  such 
as  make-span  (e  %.  [ABZ88])  and  the  amount  of  computation  required  for  finding  a  solution  is  generally 
unpredictable  [Pe82J.  Therefore,  the  construction  of  a  cheap  but  suboptimal  schedule  that  is  then  incre¬ 
mentally  repaired  to  meet  optimization  objectives  u  preferable  in  practice,  because  one  can  interrupt  the 
repair  process  and  use  the  interim  result  for  execution  when  no  more  time  it  allowed  for  further  repair.  For 
example,  dispatch  heuristics  have  very  low  computational  cost,  but  due  to  their  myopic  nature,  they  must 
be  tailored  to  particular  optimization  objectives,  Hence,  in  genera!  they  cannot  address  issues  of  balancing 
tradeoffs  with  respect  to  a  variety  of  optimization  objectives.  As  a  consequence,  they  result  in  suboptimal 
schedules.  However,  because  of  their  efficiency,  they  are  widely  used  by  practitioners  Therefore,  as  has 
already  been  pointed  out  by  other  researchers  (e.g.,  (ZDB+92,  MJPL92]),  combining  a  repair  methodology, 
such  as  a  simple  gradient  search  (KS90),  neural  networks  [Joh90],  or  the  one  advocated  in  our  work,  with 
a  dispatch  driven  scheduler  for  creation  of  the  initial  schedule  is  promising  for  real  world  scheduling  envi¬ 
ronments.  Experimental  results  reported  in  section  5  2.1  indicate  that  CABINS  can  produce  substantial 
schedule  improvements  starting  with  schedules  generated  by  several  methods  i.e.  a  number  of  dispatch 
heuristic  and  a  constraint  based  scheduler. 

Our  approach  was  evaluated  through  extensive  controlled  experimentation  on  job  shop  scheduling  prob¬ 
lems  Experimental  results,  reported  in  section  5  show  that  (1)  the  approach  is  potentially  effective  in 
capturing  user  preferences  and  optimization  tradeoffs  that  are  difficult  to  model,  (2)  it  improves  schedule 
quality  irrespective  of  method  of  initial  schedule  generation,  (3)  it  produces  high  quality  schedules  at  much 
lowet  computational  cost  as  compared  to  simulated  annealing,  a  well-known  iterative  repair  method,  and 
(4)  it  is  suitable  as  a  reactive  scheduling  method  because  it  maintains  high  schedule  quality  and  minimizes 
disruption  ill  the  face  of  execution  time  failures 
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The  test  of  the  paper  is  organized  as  follows:  section  2  gives  some  background  in  job  shop  scheduling 
and  presents  the  constraint- based  techniques  used  in  CABINS-  Section  3  introduces  case-based  schedule 
optimization.  Section  4  presents  case  representation,  indexing,  retrieval  and  application  to  the  schedule  of  a 
retrieved  revision.lt  also  presents  an  extensive  example.  Section  5  presents  experimental  results  to  validate 
the  approach.  Section  6  discusses  related  work  and  section  7  conclusions  and  future  work. 


2.  Job  Shop  Scheduling 

Job  shop  scheduling  deals  with  allocation  of  a  limited  set  of  resources  to  a  number  of  activities  associated 
with  a  set  of  jobs/orders.  The  dominant  constraints  in  job  shop  scheduling  are  temporal  activity  precedence 
and  resource  capacity  constraints.  The  activity  precedence  constraints  along  with  a  job’s  release  date  and 
due  date  restrict  the  set  of  acceptable  start  times  for  each  activity.  The  capacity  constraints  restrict  the 
number  of  activities  that  can  use  a  resource  at  any  particular  point  in  time  and  create  conflicts  among 
activities  that  are  competing  for  the  use  of  the  same  resource  at  overlapping  time  intervals.  The  goal  of  a 
scheduling  system  is  to  produce  schedules  that  respect  temporal  relations  and  resource  capacity  constraints, 
and  optimize  a  set  of  objectives.  In  our  model  we  allow  substitutable  resources  for  each  activity  of  a  job, 
thus  being  able  to  deal  with  parallel  machine  job  shop  scheduling,  a  more  complicated  version  of  the  job 
shop  scheduling  problem  [MP93J.  CABINS's  revision  based  approach  has  two-phases:  (1)  create  an  initial 
schedule  by  utilizing  any  method  (e.g.  dispatching  rules),  and  (2)  improve  the  (possibly)  suboptimal  schedule 
that  was  generated  in  the  first  step  so  as  tu  incorporate  user  preferences  and  tradeoffs. 

In  the  rest  of  this  section,  we  present  the  job  shop  scheduling  problem  within  the  framework  of  constraint 
satisfaction,  and  present  the  search  strategy  that  is  used  to  propagate  the  effects  of  repair  actions  in  CABINS. 


2.X.  Constraints 

The  job  shop  scheduling  problem  requires  scheduling  a  set  of  jobs  J  =  {Ji,.-.-.  h)  on  a  set  of  physical 
resources  RES  =  {Ri,  . ,  Rm}-  Each  job  Ji  consists  of  a  set  of  operations/activilirs  A1  =  (A), ,  Aj,,}  to 
be  scheduled  according  to  a  process  routing  that  specifies  a  partial  ordering  among  these  activities  (e.g.,  A| 
BEFORE  A}). 

Each  job  Ji  has  a  release  date  rdi  that  signifies  the  earliest  time  the  job  can  be  started  and  a  job  due 
date  dd|,  by  which  the  job  should  be  finished.  Each  activity  A1,  has  a  fixed  duration  du\  and  a  variable 
start  time  *t|  The  domain  of  possible  start  times  of  each  activity  is  initially  constrained  by  the  release 
and  due  dates  of  the  job  to  which  the  activity  belongs,  In  order  to  be  successfully  executed,  each  activity 
A-  requires  pj  different  resources  (e.g.,  a  milling  machine,  a  jig  and  a  machinist)  R'  (1  <  j  <  p[),  for 
each  of  which  there  may  be  a  pool  of  physical  resources  from  which  to  cnoose,  fl[;  =  {rj;1 , .  * ,  rU}'  with 
rl)t  £  RES(  1  <  It  <  qjj)  (e.g.,  several  possible  milling  machines). 

More  formally,  the  problem  can  be  defined  as  follows: 


YAMABLES  •’  A  vector  of  variables  is  associated  with  each  activity,  A,'(l  <  I  <  n,  1  <  »  <  m),  which 
includes: 

1.  the  activity  start  time,  st'„  and 

2.  each  resource  rejuiremenf,  Rj;(l  <  j  <  pj)  for  which  the  activity  has  several  alternatives. 

CONSTRAINTS  :  The  uon-unary  constraints  of  the  problem  arc  of  two  types. 

1.  Precedence  constraints  defined  by  the  process  routings  translate  into  linear  inequalities  of  the 
type  it1,  +  du[  <  sfj  (i.e.  A[  BEFORE  A}  ), 
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2.  Capacity  constraints  that  restrict  the  use  of  each  resource  to  only  one  activity  at  a  time  translate 
into  disjunctive  constraints  of  the  form:  (VpVyJl*,  ^  V  «/*  +  du*  <  si  j  V  sfj  +  du}  <  stf. 
Constraints  simply  express  that,  unless  they  use  different  resources,  two  activities  /if  and  Aj 
cannot  overlap  1 . 


Time  is  assumed  discrete,  i.e.,  activity  start  times  and  end  times  can  only  take  integer  values  Each 
resource  requirement  Jjjj  has  to  be  selected  from  a  set  of  resource  alternatives,  ffy  C  RES  These  constraints 
include  non-relaxable  release  dates,  and  initially,  non-rclaxable  due  dates  between  which  all  activities  in  a 
job  need  to  be  performed. 


2.2.  Objectives  and  Preferences 

In  practice,  scheduling  objectives  are  numerous,  complex,  often  conflicting  and  the  mathematics  of  the  prob¬ 
lem  can  be  extremely  difficult  with  even  the  simplest  of  objectives  [Fre82].  Below,  we  define  the  objectives, 
that  are  among  the  most  common  in  the  literature  (e.g.  [Fre82]),  that  we  used  to  develop  the  performance 
evaluation  of  CABINS.  These  objectives  are  mathematical  simplifications  of  state-dependent  objectives  that 
are  difficult  to  model  precisely.  For  example,  an  optimisation  criterion  such  as  WEIGHTED  TARDINESS J  x 
WIPS  could  be  induced  by  CABINS  if  user  gave  consistent  evaluation  of  schedules,  but  cannot  be  easily 
represented  in  ways  that  can  he  explored  by  traditional  schedule  approaches. 


Waiting  time  (it’*) :  is  the  time  that  elapses  between  the  completion  of  the  preceding  activity  A|_)  (or 
rd|,  if  i  =  1  )  and  the  start  of  processing  A[. 

Total  waiting  time  (Hi)  i  is  the  sum  of  waiting  time  of  all  activities  that  belong  to  J'.  Clearly  IV’i  = 
Completion  time  (Ci)  i  is  the  time  at  which  procesamg  of  Ji  finishes  We  have  the  equality:  Ci  = 

«HCli  (»?+*!) 

Lateness  (h)  :  is  simply  the  difference  between  the  completion  time  and  the  due  date  of  Jt :  Li  -  Ci-dd|. 

Tardiness  (7)) :  is  delay  in  the  completion  of  Ji  against  its  due  date  drf j.  Note  that  1}  always  takes  non-zero 
value.  Thus  Ti  =  max(O.Li). 

Flowtime  (fi)  i  is  the  amount  of  time  that  Ji  spends  in  the  system,  /j  =  Ci-rdi  or  F,  = 

Make-span  (C„,„)  i  is  the  latest  completion  time  of  the  entire  orders.  (?mat  =  maxC, 

Work-in-Process  Inventory  (It7/?)  :  is  the  summation  of  total  waiting  time.  WIP  -  IV, 

Weighted  Tardiness  (X* i ) :  is  the  weighted  average  of  tardiness.  Weight  is  considered  as  a  penalty  cost 
of  being  tardy.  Twt  ~  £"-■  iv,X, 


The  quality  of  a  schedule  is  a  function  of  the  extent  to  which  it  achieves  user's  preferences.  We  illustrate 
the  necessity  of  having  user’s  preferences  in  the  scheduling  system  by  using  a  very  simple  example.  We 
assume  the  simplest  factory  with  a  single  machine  and  two  jobs.  Each  job  consists  of  a  single  activity  to  be 
processed  on  the  factory  machine  let  us  further  assume  that  the  two  jobs  are  released  to  the  factory  floor 
at  the  same  time. 

Figure  1  shows  two  schedule  results  for  this  problem.  Suppose  schedule- 1  is  generated  In  this  schedule, 
job  B  finishes  before  its  due  date  but  job  A  is  tardy.  The  WIP  of  job  A  is  indicated  in  figure  1  (the  WIP 
of  job  B  is  zero)  Suppose  one  wishes  to  revise  the  schedule  to  reduce  the  tardiness  of  job  A.  In  this  simple 


'Their  constraints  have  lo  br  generabzed  when  dealing  with  resources  of  capacit>  larger  than  one. 
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Figure  1:  Example  of  Conflicting  Objectives 

schedule,  the  only  possible  repair  is  to  switch  the  portions  of  job  A  and  job  B.  The  schedule  resulting  from 
this  switch  is  schedule-2.  In  schedule-2,  neither  job  is  tardy  but  the  WIP  in  schedule-2  (the  WIP  of  job  B) 
is  larger  than  in  schedule-1  Even  in  this  extremely  simple  example,  it  is  difficult  to  decide  which  schedule 
is  of  higher  quality  without  taking  into  consideration  the  preferences  of  the  user  Simply  adding  WIP  plus 
weighted  tardiness  and  minimising  the  sum  may  not  be  realistic  since  the  relative  importance  of  each  of 
these  objectives  in  the  overall  sum  reflects  the  tradeoffs  the  user  is  willing  to  make.  These  tradeoffs  may 
depend  upon  many  factor*,  such  as  the  importance  of  the  client  of  each  job,  past  shipping  records,  load  of 
a  factory/warehouse  and  so  on.  The  combination  of  those  factors  produces  enormous  number  of  contexts 
in  which  user  preferences  are  considered,  thus  making  user’s  preferences  difficult  to  capture  and  represent  a 
priori  in  the  problem  model.  That  is  the  reason  that  the  authors  think  acquiring  preferences  adaptively  is 
important. 


2.3.  Constraint-Based  Search  Procedure 

The  constraint-based  search  procedure  used  in  CABIN’S  for  applying  a  selected  repair  action  (see  section  4.4) 
is  based  on  [SF90,  Sad91).  Search  is  interleaved  with  the  application  of  consistency  enforcing  mechanisms  and 
variable/value  ordering  heuristics  that  attempt  to  avoid  dead-end  slates.  A  search  state  is  associated  with 
each  partial  solution  Each  search  state  defines  a  new  constraint  satisfaction  problem  whose  variables  are  the 
variables  that  have  not  yet  been  instantiated  and  whose  constraints  are  the  initial  problem  constraints  along 
with  constraints  reflecting  current  assignments.  A  schedule  is  built  by  opportunistically  selecting  an  activity 
to  be  scheduled  and  assigning  to  it  a  reaerosfion,  i.e.  a  resource  and  a  start  time.  Each  time  a  new  activity 
is  scheduled,  new  constraints  are  added  to  the  initial  scheduling  constraints  that  reflect  the  new  activity 
reservation.  These  new  constraints  are  then  propagated  (consistency  checking).  If  an  inconsistency  (i.e., 
constraint  violation)  is  detected  during  propagation,  the  system  backtracks.  Otherwise  the  scheduler  selects 
a  new  activity  to  schedule  and  a  reservation  for  that  activity.  The  process  terminates  when  ail  activities 
have  been  scheduled  successfully. 

More  specifically,  search  proceeds  according  to  the  following  steps: 

J.  If  all  operations  have  been  scheduled  then  stop,  else  go  on  to  step  2; 

2,  Apply  the  consistency  enforcing  procedure; 

3.  If  a  dead-end  is  detected  then  backtrack  (i.e.  select  an  alternative  reservation  if  one  is  left  and  go  back 
to  step  1,  otherwise  stop) 


4.  Select  the  next  operation  to  be  scheduled  ( variable  ordering  heuristic); 

6.  Select  a  promising  reservation  for  that  operation  (mint  ordering  heuristic), 

6.  Create  a  new  tcani  state  by  adding  the  new  reservation  assignment  to  the  current  partial  schedule 
and  go  back  to  step  1; 

The  details  of  each  step  are  as  follows; 

Consistency  Enforcement :  The  consistency  enforcing  procedure  is  a  hybrid  procedure  that  differentiates 
between  precedence  constraints  and  capacity  constraints  It  guarantees  that  dead-end  states  only  occur 
as  the  result  of  capacity  constraint  violations.  Essentially,  consistency  with  respect  to  precedence 
constraints  is  enforced  by  updating  in  each  search  state  a  pair  of  earliest/latest  possible  start  times  for 
each  un-scheduled  operation. 

Consistency  enforcement  with  respect  to  capacity  constraints  tends  to  be  significantly  more  expensive 
due  to  the  disjunctive  nature  of  these  constraints.  For  capacity  constraints,  a  forward  checking  type 
of  consistency  checking  is  generally  carried  out  by  the  system.  Whenever  a  resource  is  allocated  to 
an  operation  over  some  time  interval,  the  forward  checking  procedure  checks  the  set  of  remaining 
possible  start  times  of  other  operations  requiring  that  resource,  and  removes  those  start  times  that 
would  conflict  with  the  new  assignment. 

Variable  Ordering :  Because  scheduling  is  KP-hard,  it  is  important  to  focus  search  in  ways  that  avoid 
dead-end  states.  This  is  accomplished  by  utilising  good  variable  (i.e.,  activity)  and  value  (i.e.,  reserva¬ 
tion)  ordering  heuristics.  A  variable  ordering  determines  which  activity  it  going  to  be  scheduled  next 
and  value  ordering  determines  which  reservation  should  be  assigned  to  the  selected  activity.  The  run- 
able  ordering  heuristic  utiliied  in  the  system  is  called  Activity  Resource  Reliance  (ARR)  [SF90]  and 
selects  the  most  critical  activitg  first,  i.e.,  the  activity  with  the  highest  probability  of  being  involved 
in  a  capacity  constraint  violation  over  particular  time  intervals.  For  more  details  on  the  approach,  see 
[SF90] . 

Value  Ordering  :  Once  the  activity  to  be  scheduled  next  has  been  selected,  the  value  ordering  heuristic 
determines  which  reservation  to  assign  to  the  activity.  The  two  value  ordering  heuristics  relevant  to 
this  paper  are: 

Least  Constraining  Value  Ordering  (LCV)  i  This  heuristic  selects  the  reservation  that  is  the 
least  likely  to  prevent  other  activities  from  being  scheduled.  LCV  uses  an  unbiased  utility-function 
(see  figure  2)  for  each  activity,  i.e.  there  is  no  preference  for  a  particular  start  time  out  of  the 
activity's  available  start  times. 

Greedy  Value  Ordering  (GV)  i  This  heuristic  selects  a  reservation  based  on  local  preferences  that 
arc  expressed  via  static  piece-wist  linear  biased  utility-function  associated  with  each  activity  (see 
figure  2).  Thi;  biases  value  ordering  to  prefer  activity  start  times  with  high  utility  values.  For 
scheduling  problems  with  substitutable  resources,  static  utilities  that  express  differential  resource 
preferences  are  used  in  the  selection  of  an  activity’s  reservation 


Experiments  in  [SF90] 2  on  some  rather  small  job  shop  problems  (each  with  20  activities)  indicate  that  the 
ARR  variable  ordering  with  LCV  value  ordering  produces  suboptimai  schedules  with  minimal  backtracking; 
ARR  variable  ordering  witli  GV  value  ordering  with  statically  predetermined  utility  functions,  henceforth 
referred  to  as  constraint-based  scheduling  (CBS),  was  shown  to  produce  high  quality  schedules  as  compared 
to  the  SMI'  heuristic  ((KYS9|). 

In  CABINS,  schedule  revision  proceeds  iteratively,  one  activity  at  a  time.  The  set  of  activities  that  get 
involved  in  constraint  violations  as  a  result  of  repairing  one  activity  is  the  conflict  set  of  the  repair  The  repair 


2The  experiments  were  run  on  20  randomly  generated  acheduling  probleme. 
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Figure  2:  Utility-Functions 


process  unschedules  the  activities  in  the  conflict  set  and  modifier  the  bias  of  the  utility  functions  associated 
with  them.  This  bias  reflects  the  effects  of  learning  context-dependent  user  preferences  and  evaluations  of 
repair  outcomes  that  have  been  stored  in  the  case  base.  The  search  procedure  with  the  modified  utility 
functions,  ARR  variable  ordering  and  GV  value  ordering  is  used  to  schedule  the  conflict  set  activities  that 
got  unscheduled  during  repair,  fn  other  words,  each  time  an  activity  s  repaired,  CBS  is  used  to  reschedule 
a  subset  of  the  activities  (i.e.  the  members  of  the  conflict  set)  of  the  overall  schedule  with  utility  functions 
list  have  been  adaptively  modified  based  on  information  in  the  case  base.  Section  4.4  describes  the  repair 
process  in  detail 


3.  Case-based  Schedule  Optimisation 


In  order  to  optimue  schedules  to  user’s  satisfaction,  we  need  to  know  context-dependent  user  preferences  and 
represent  them  in  the  scheduling  system  to  be  exploited  in  the  reasoning  process.  Rule-based  approaches, 
while  having  the  potential  to  capture  context-dependent  tradeoffs  in  rules,  require  considerable  knowledge 
acquisition  effort  [Pre90j.  Our  approach  uses  case-based  reasoning  (CBR)  which  has  the  potential  for  deal¬ 
ing  with  noisy  data  (RK92,  AKA91],  acquiring  user  knowledge  in  complex  domains  [Cha93,  MBS88),  and 
expending  leas  effort  in  knowledge  acquisition  compared  with  knowledge  acquisition  for  rule-based  systems 
[SM91,  LMB91], 

Because  of  the  characteristics  of  the  scheduling  domain  described  in  the  prr  ‘ious  section  and  our  interest 
in  capturing  context  dependent  user  preferences,  CBR  seems  a  natural  method  for  knowledge  acquisition. 
However,  applying  CBR  to  schedule  improvement  a  numerical  optimisation  problem,  is  very  challenging.  In 
general,  CBR  has  been  used  for  ill-structured  symbolic  problems,  such  as  plsnning  [Ham89,  KH92,  Vel92),  le¬ 
gal  reasoning  [Ash87,  RA88),  argumentation  [Syc89],  conceptual  design  [SGK+91] ,  medical  diagnosis  [Kot88] 
where  the  primary  concern  has  been  plausibility  or  correctness  of  the  resulting  artifset  (plan,  argument,  de¬ 
sign)  and  computational  efficiency  of  the  process  rather  then  artifact  quality. 

The  challenges  we  faced  were  to  decide  what  constitutes  a  case  in  the  domain  of  schedule  optimisation 
and  what  the  case  indices  should  be.  The  intuitive  answer  would  he  to  consider  a  whole  schedule  as  a  case. 
This  solution  it  attractive  since,  if  the  tight  information  could  be  tr&nsfetred  from  one  scheduling  scenario 
to  another,  or  with  little  adaptation,  the  new  problem  would  be  solved  with  relative  ease.  However,  because 
of  the  high  degree  of  nonlinearity  of  scheduling  constraints  and  objectives,  a  very  small  difference  between 
an  input  problem  specification  and  the  problems  in  the  ease  base  can  in  general  result  in  large  variations  in 
the  results  both  in  terms  of  amount  of  modification  needed  and  the  quality  of  resulting  schedule.  A  second 
difficulty  with  respect  to  having  a  whole  schedule  as  a  case  came  iu  the  form  of  what  indices  to  choose. 
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Indexing  a  cate  in  terms  of  the  goals  that  must  he  achieved  and  problems  that  must  be  avoided  [Ham89]  is 
a  good  guideline  and  has  served  many  CBR  systems  well.  However,  in  our  domain,  the  goals  to  be  achieved 
(the  optimization  criteria)  cannot  be  explicitly  stated  since  they  reflect  context-dependent  user  preferences 
and  tradeoffs.  Even  if  the  optimization  objectives  were  explicit,  because  of  the  nonlinearities  of  the  problem, 
retrieving  a  schedule  in  which  the  achieved  objectives  were  the  same  as  the  desired  ones  in  the  current 
problem  would  give  little  or  no  help  in  adapting  the  retrieved  schedule  to  the  current  problem  specifications. 
Moreover,  because  of  unpredictable  ripple  effects  of  constraint  propagation  and  tight  constraint  interactions, 
the  problems  to  be  avoided  are  not  at  all  obvious,  neither  can  they  be  discovered  since  a  causal  model  for 
scheduling  cannot  be  assumed. 

Since  it  is  impossible  to  judge  a  priori  the  effects  of  a  scheduling  decision  on  the  optimization  objectives, 
a  scheduling  decision  mutt  be  applied  to  a  schedule  and  its  outcome  must  be  evaluated  in  terms  of  the 
resulting  effects  on  scheduling  objectives.  Therefore,  having  a  single  scheduling  decision  as  a  case  seemed  to 
provide  advantages  in  terms  of  focus  and  traceability  of  the  problem  solving  process.  Focus  and  traceability 
mean  that  we  could  capture  a  user's  evaluation  of  the  results  of  a  single  scheduling  decision  in  a  case,  and, 
if  the  result  was  unacceptable,  we  could  apply  another  scheduling  decision  to  the  same  scheduling  entity 
until  either  all  available  scheduling  decisions  had  been  exhausted  or  an  acceptable  result  had  been  obtained 
Therefore,  it  became  clear  that  it  was  better  to  have  a  single  activity /operation  of  a  scheduling  job  as  the 
"scheduling  entity”  on  which  a  scheduling  decision  was  applied.  Since  the  result  of  a  scheduling  decision 
needed  to  be  evaluated  with  regard  to  the  optimization  preferences  for  a  schedule  as  a  whole,  it  is  clear  that 
constructive  methods  which  incrementally  augment  a  partial  schedule  at  every  scheduling  decision  point 
would  be  unsuitable  for  our  purposes.  Moreover,  contextual  information,  -hich  can  only  be  provided  by 
having  a  complete  schedule,  is  very  useful  in  applying  CBR.  Therefore,  revision-based  scheduling  was  chosen 
as  the  underlying  scheduling  methodology. 

Hence  in  CABINS,  a  case  describes  the  application  0/  a  schedule  revision  decision  on  a  single  activity  of  a 
job  Operationalization  of  a  schedule  revision  decision  is  done  by  means  of  a  schedule  repair  action.  We  have 
identified  two  classes  of  schedule  repair  actions  (i.e.  strategy  and  tactic),  described  in  detail  in  section  4.  We 
use  constraint  propagation  to  propagate  the  effects  of  a  schedule  repair  action  to  the  rest  of  the  schedule. 
Each  application  of  a  repair  results  in  a  new  schedule.  The  search  space  of  CABINS  is  the  space  of  complete 
seh>  doles  that  incorporate  acceptable  user  optimization  tradeoffs.  Hence  the  predictive  case  features  that 
are  suitable  for  case  indexing  should  be  ones  that  capture  good  tradeoffs.  Although  schedule  optimization  is 
ill-structured,  we  make  the  hypothesis  that  there  are  regularities  of  the  domain  that  can  be  captured,  albeit 
in  an  approximate  manner,  in  these  features.  In  CABINS,  indices  are  divided  into  three  categories.  The 
first  category  consists  of  the  global  features.  Since  the  results  of  schedule  revision  associated  with  a  single 
activity  pertain  to  the  whole  schedule,  global  features  that  express  characteristics  of  a  whole  schedule  are 
relevant  and  operate  as  contextual  information  for  selection  of  a  particular  repair  action.  The  local  /natures 
comprise  the  second  category.  Since  it  is  not  possible  to  predict  in  general  the  bounds  of  repair  necessitated 
by  application  of  a  repair  action  (due  to  constraint  ripple  effects),  and  since  reasoning  about  the  effects  of 
a  repair  action  on  the  whole  schedule  a  priori  would  amount  to  unlimited  lookahead  analysis  which  is  in 
general  intractable,  we  confine  the  range  of  lookahead  analysis  to  a  limited  repair  time  homo n  (see  section 
4.1).  Associated  with  this  time  horizon,  there  are  local  features  that  allow  CABINS  to  estimate  the  effects 
of  each  repair  action. 

The  schedule  resulting  from  application  of  a  repair  action  must  be  evaluated  in  terms  of  user-defined 
tradeoffs.  The  user  cannot  predict  the  effects  of  modification  actions  on  schedule  correctness  or  quality  since 
a  modification  could  result  in  worsening  schedule  quality  or  introducing  constraint  violations.  Nevertheless, 
the  user  can  perform  consistent  evaluation  of  the  results  of  schedule  revisions.  This  evaluation  is  recorded 
in  the  case  as  part  of  the  case’s  repair  history.  The  repair  history  constitutes  the  third  category  of  case 
features  Therefore,  the  case  base  incorporates  a  distribution  of  examples  that  collectively  capture  repair 
performance  tradeoffs  under  diverse  scheduling  circumstances. 

CABINS  searches  vhe  space  of  complete  schedules  Control  for  this  search  is  provided  by  CBR  in  two 
ways*  First,  search  control  is  provided  through  case-baaed  selection  of  the  next  repair  action  to  be  applied 
and  second  through  case-based  evaluation  of  the  outcome  for  the  schedule  that  resulted  from  application 


of  a  selected  repair  action.  The  global  and  local  features  are  the  indices  that  are  used  to  retrieve  a  case 
that  suggests  the  next  repair  action  to  be  applied  The  features  associated  with  the  repair  history  arc 
used  to  retrieve  cases  that  suggest  evaluations  of  a  repair  outcome.  For  a  more  detailed  description  of  case 
representation  and  indexing,  see  section  4  1 


4.  CABINS  Overview 


In  CABINS,  there  are  two  general  types  of  repairs:  repair  strategies  and  repair  tactics.  A  repair  strategy  is 
associated  with  a  particular  high  level  description  of  classes  of  schedule  defects.  Each  repair  strategy  has  a 
variety  of  repair  tactics  associated  with  it.  The  repair  tactics  are  appropriate  for  particular  specialisations 
of  the  defect  classes.  We  have  identified  two  general  types  of  repair  strategies:  local  patching  and  model 
modification  Local  patching  is  the  selection  of  repair  actions  that  result  in  changing  the  sequence  of  activities 
allocated  to  different  resources,  or  rearranging  resource  assignments.  Local  patching  is  in  general  less  costly 
and  disruptive  to  factory  operations.  For  example,  if  the  repair  goal  is  to  reduce  job  tardiness,  specific 
local  patching  strategies  include  “reduce  the  alack  between  activities  in  the  tardy  job”,  and  “reduce  the 
idle-time  of  resources  needed  by  activities  in  the  tardy  job” .  Model  modification  reformulates  the  problem 
by  changing  model  parameters,  such  as  the  number  of  jobs  to  be  scheduled,  or  global  constraints  such  as 
changing  release  or  due  dates,  increasing  resource  capacity  or  increuing  number  of  shifts.  Model  modification 
strategies  facilitate  the  solution  of  the  problem,  since  they  amount  to  global  constraint  relaxations.  However, 
in  practice,  model  modification  strategies  are  costly  to  implement  (eg.,  buy  new  equipment,  pay  for  extra 
shifts  in  a  factory,  subcontract  jobs  to  outside  contractors).  The  default  CABINS  strategy  is  local  patching, 
a  computationally  more  challenging  task  since  the  system  must  improve  the  schedule  without  relaxing  the 
already  imposed  constraints  (except  due  date  constraints).  If  local  patching  is  unsuccessful  in  fulfilling  the 
repair  goal,  the  repair  episode  is  considered  a  failure.  Our  experiments  were  run  within  these  more  stringent 
assumptions 

Figure  3  depicts  the  overall  architecture  of  CABINS.  CABINS  is  composed  of  three  modules:  (1)  an 
initial  schedule  builder,  (2)  an  interactive  schedule  repair  (case  acquisition)  module  and  (3)  an  automated 
schedule  repair  (ca6e  re-use)  module. 

CABINS  can  operate  in  the  following  modes  that  exhibit  different  levels  of  autonomy: 

•  Knowledge  acquisition  interactive  mode  to  acquire  user  p'eferences  and  generate  the  rase  base. 

•  Decision-support  interactive  model  where  the  previously  acquired  case  base  that  incorporates  uset 
preferences  suggests  revision  actions  and  evaluation  outcomes  to  the  user  who  can  accept  a  suggestion 
or  override  it  with  a  new  suggestion, 

•  Automatic  mode  where  previously  acquired  user  preferences  are  re-used  to  guide  scheduling  decisions 
without  any  interaction  with  the  user, 

In  the  experiments  reported  in  section  5,  CABINS  operated  autonomously.  The  repair  process  in  au¬ 
tonomous  operating  mode  has  the  following  basic  steps- 

1.  A  job  in  the  initial  suboptimal  schedule  is  randomly  identifies  to  be  repaired.  The  random  job  selection 
is  necessary  since  CABINS  does  not  have  explicit  optimisation  criteria  that  it  could  use  to  select  jobs 
to  be  repaired  in  a  mote  informed  fashion. 

2  The  job  under  current  repair  consideration  is  called  the  focaLjob  and  the  activity  under  current  repair 
consideration  is  called  the  focai. activity.  Repair  is  performed  one  activity  at  a  time.  Activities  in 
a  focal-job  are  repaired  in  a  forward  fashion  starting  with  the  earliest  activity  of  that  job  that  has 
“enough"  upstream  slack  This  mechanism  focuses  attention  on  activities  that  have  enough  slack  so 
they  can  be  moved,  thus  (a)  avoiding  unnecessary  compulations,  and  (b)  limiting  the  amount  of  tipple 
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Figure  3.  CABINS  Architecture 
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effects  (schedule  disruption)  that  could  be  caused  by  moving  activities  that  are  too  tightly  scheduled 
and  whose  move  would  cause  many  constraint  violations  s 

3  A  repair  strategy/tactic  is  selected  for  the  current  problem  using  CBR  and  is  applied.  Application  of  a 
repair  tactic  (described  in  section  4.4  )  consists  of  three  parts'  (a)  identifying  the  activities,  resources 
and  time  intervals  that  will  be  involved  in  the  repair,  i.e.  the  current  conflict  set,  (b)  change  the  utility 
functions  associated  with  activities  in  the  conflict  set,  and  (c)  using  the  constraint-directed  scheduler 
with  utilities  assigned  in  step  (b)  to  make  the  resource  reservations  for  the  activities  identified  in  step 
(a). 

4.  After  a  repair  has  been  executed,  CBR  is  used  to  predict  and  evaluate  the  repair  outcome  in  the 
context  of  the  current  case-base. 

5.  If  repair  is  deemed  a  success,  find  next  activity  to  repair,  else  (if  repair  outcome  is  a  failure),  CBR  is 
invoked  to  select  the  next  repair  tactic  to  repair  the  current  focal -activity. 


4.1,  Case  Representation 

The  repair  process  should  exploit  knowledge  relating  both  to  the  continuing  validity  of  various  scheduling 
decisions,  the  flexibility  of  current  time  and  capacity  constraints,  the  trade-offs  that  are  implied  by  a  partic¬ 
ular  repair,  and  whether  the  repair  was  successful  or  unsuccessful  according  to  the  user’s  judgment.  Figure 
4  shows  the  information  content  of  a  case.  Appendix  A  shows  an  example  of  a  case  instance  that  is  in 
CABlNS’s  case  base. 

A  case  describes  the  application  of  a  particular  repair  action  to  an  activity.  Because  of  the  ill-structuredness 
of  the  domain,  case  features  are  heuristic  approximations  that  reflect  regularities  of  revision-based  schedul¬ 
ing.  For  example,  one  of  the  regularities  that  would  be  useful  to  represent  would  be  repair  flexibility,  i.e 
the  notion  of  how  much  freedom  there  is  in  the  current  schedule  for  moving  an  activity  to  a  new  position. 
Global  esse  features  (figure  4)  reflect  potential  repair  flexibility  for  the  schedule  as  a  whole.  High  resource 
utilisation,  for  example,  often  indicates  a  tight  schedule  without  much  repair  flexibility.  High  standard 
deviation  of  resource  utilization  indicates  the  presence  of  highly  contended-for  resources  which  in  turn  in¬ 
dicates  low  repair  flexibility.  Local  features  reflect  flexibility  for  schedule  revision  within  limited  temporal 
bounds.  In  particular,  the  temporal  bound  that  CABINS  uses  is  a  time  interval  called  rrpatr  lime  horiio n 
The  repair  time  horizon  of  a  foe rd .activity  is  the  time  interval  between  the  end  of  the  activity  preceding  the 
focal-activity  in  the  same  focal  job  and  the  end  of  the  focal-activity  (see  figure  5).  The  local  features  that  we 
have  identified  are  in  the  same  spirit  as  those  utilized  in  (OST88).  For  example,  predictive-shift -gain  predicts 
how  much  overall  gain  will  be  achieved  by  moving  the  current  focal  .activity  earlier  in  its  time  horizon.  In 
particular,  it  predicts  the  likely  reduction  of  the  focal  activity's  waiting  time  when  moved  to  the  left  within 
the  repair  time  horizon. 

The  repair  history  records  the  sequence  of  applications  of  successive  repair  actions,  the  repair  effects 
and  the  repair  outcome.  Repair  effects  describe  the  impact  of  the  application  of  a  repair  action  on  sched¬ 
ule  optimization  objectives  (e  g.,  weighted  tardiness,  WIP).  Typically  these  effects  reflect  tradeoffs  among 
different  objectives.  A  repair  outcome  is  the  evaluation  assigned  to  the  set  of  effects  of  a  repair  action 
and  takes  values  in  the  set  ['acceptable',  'unacceptable']  This  judgment  is  made  in  the  training  phase  and 
gets  recorded  in  the  case  base.  An  outcome  is  'acceptable'  if  the  tradeoffs  involved  in  the  set  of  effects  for 
the  current  application  of  a  repair  action  is  judged  acceptable  If,  during  case  acquisition,  the  outcome  is 
judged  as  "unacceptable" ,  the  application  of  the  repait  tactic  is  considered  a  failure  and  an  explanation  that 
expresses  tradeoffs  with  respect  to  balancing  favorable  and  unfavorable  outromca  on  optimization  objectives 
is  provided.  If  during  CBR  repait  the  repair  outcome  is  deemed  unacceptable,  another  tactic  is  selected  from 
success  cases  to  repair  the  same  activity,  using  aa  indices  global  and  local  case  features,  the  failed  tactic, 
and  the  indication  of  the  failed  outcome.  This  CBR  invocation  retrieves  similar  past  failures  of  the  tactic 
that  were  successfully  repaired  and  the  tactic  that  was  eventually  successful  in  fixing  the  past  failure.  The 


3 In  the  current  implementation,  "enough"  upstream  slaelt  ia  heurittically  determined  a*  twice  the  tardiness  of  the  focatiob 
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Figure  4:  Cast  Representation 
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assumption  here  is  that  a  similar  outcome  for  the  6ame  tactic  implies  similarity  of  causal  structure  between 
the  past  and  current  case.  Therefore,  the  eventually  successful  tactic  of  a  similar  failure  can  potentially  be 
successful  in  the  current  problem 


4.2.  Case.  Acquisition 

In  CABINS,  the  session  starts  with  an  empty  case-base.  A  set  of  training  problems  are  presented  to  the 
user  who  interacts  with  CABINS  to  repair  schedules  by  hand.  At  first,  the  user  selects  the  repair  tactic  that 
is  deemed  to  be  appropriate  and  uses  CABINS’s  tactic  application  procedure  (see  section  4.4)  to  apply  the 
chosen  tactic  to  the  current  schedule. 

The  effects  of  the  repair  are  calculated  An  effect  describes  the  result  of  the  repair  with  respect  to 
one  or  more  repair  objectives.  Effects  pertain  to  either  the  schedule  as  a  whole  or  to  a  job  Possible  effects 
pertaining  to  a  schedule  as  a  whole  are*  weighted  tardiness,  average  resource  utilisation,  deviation  of  resource 
utilization,  total  schedule  WiP.  Effects  that  pertain  to  a  job  are  changes  in  the  tardiness  of  the  job,  changes 
in  work-in-process  inventory,  or  changes  in  resource  assignment.  So,  for  example,  the  tradeoff  between 
utilizing  a  less  preferred  machine  to  reduce  a  job’s  tardiness  can  be  reflected  in  these  effects.  Due  to  tight 
constraint  interactions,  these  effects  are  ubiquitous  in  job  shop  scheduling  and  make  schedule  optimisation 
extremely  hard.  When  application  of  a  repair  tactic  produces  a  feasible  result,  the  user  must  decide  whether 
the  resulting  schedule  is  acceptable  or  not  based  upon  those  calculated  effects.  An  example  of  these  effect* 
is  shown  in  Appendix  A. 

An  outcome  »  judged  as  unacceptable,  if  the  schedule  resulting  from  the  application  of  the  revision 
heuristic  does  not  make  any  improvement  with  respect  to  the  user's  criteria.  This  could  happen  because 
harmful  effects  outweighed,  in  the  user’s  judgment,  the  effected  improvement.  For  example,  if  reduction  of 
job  tardiness  enforces  increased  utilization  of  low-quality  machine,  although  the  total  cost  of  this  repair  may 
be  low,  it  may  be  unacceptable  to  a  user  who  worries  that  the  quality  of  resulting  products  might  be  low. 
Therefore  such  a  repair  might  be  judged  as  unacceptable.  The  user’s  judgment  as  to  balancing  favorable  and 
unfavorable  effects  related  to  a  particular  optimization  objective  constitute  the  explanations  of  the  repair 
outcome.  The  user  supplies  an  explanation  in  terms  of  rating  the  importance  of  each  effect  (denoted  by 
"salience”  in  figure  4).  At  the  end  of  each  repair  iteration,  the  applied  repair  tactic,  the  effects  of  the  repair 
and  user  judgment  /  explanation  as  to  the  repair  outcome  are  recorded  in  a  case  along  with  the  current 
problem  features.  If  the  effects  are  acceptable  to  the  user,  the  repair  outcome  is  recorded  as  ”acceptable” 
and  the  user  tries  to  repair  another  activity  If  the  user  does  not  like  the  tradeoffs  that  are  incorporated  in 
the  repair  effects,  then  the  outcome  of  the  current  repair  tactic  ("unacceptable”),  the  effects  calculated  by 
CABINS  and  the  salience  assigned  by  the  user  are  recorded  in  the  repair  history  of  the  case.  Subsequently, 
the  user  tries  to  utilize  another  repair  tactic  to  repair  the  same  activity. 

The  process  continues  until  an  acceptable  outcome  is  reached,  or  failure  is  declared.  Failure  is  declared 
when  all  available  tactics  have  been  used  to  repair  an  activity,  but  the  user  finds  each  repair  outcome 
unacceptable.  The  sequence  of  application  of  successive  repair  actions,  the  effects,  user’s  judgment  and 
explanation  in  case  of  failed  application  are  recorded  in  the  repair  history  of  the  case.  Two  remarks  are 
in  order  here  with  respect  to  case  acquisition.  First,  a  new  case  is  acquired  only  when  a  new  activity  is 
under  repair.  When  an  activity  is  repeatedly  repaired  due  to  unacceptable  repair  tactic  application  results, 
no  new  case  is  acquired,  but  the  repair  history  of  the  same  case  is  augmented  by  each  successive  repair 
tactic  application,  its  effects  and  outcome.  In  this  way,  a  number  of  cases  are  accumulated  in  the  case-base. 
In  section  5,  we  describe  how  the  esses  used  in  our  experiments  were  acquired  Moreover,  in  section  5.3 
we  report  current  experimental  results  to  investigate  the  tradeoffs  incurred  when  CABINS  operates  with 
different  size  case  bases. 
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4.3.  Cue  Retrieval 


Once  CABINS  has  constructed  a  case-base  from  training  data  it  can  perform  schedule  repair  without  any 
interaction  with  its  user.  Retrieved  cases  are  for  three  purposes,  selection  of  a  repair  tactic  to  be  applied, 
evaluation  of  the  resulting  schedule  after  application  of  the  selected  repair  tactic,  and,  in  case  of  failure, 
retrieval  of  a  tactic  that  had  fixed  a  previous  similar  failure  In  each  of  these  three  situations,  CABINS 
utilises  a  different  set  of  indices  for  case  retrieval.  In  order  to  retrieve  cases  to  select  a  repair  tactic,  global 
and  local  features  of  the  current  cue  (the  current  focal  .activity)  are  used.  The  process  of  applying  a  repair 
tactic  is  described  in  section  4  4. 

After  a  repair  has  been  applied  and,  if  the  result  is  a  feasible  schedule,  repair  evaluation  is  performed 
through  CBR.  Using  the  effect  feature*  (type,  value,  and  salience)  as  new  indices,  CBR  is  invoked  and 
returns  an  outcome  in  the  set  (acceptable,  unacceptable) 

If  the  outcome  of  current  revision  is  decided  as  unacceptable,  CABINS  performs  another  CBR  invocation 
using  as  indices  the  conjunction  of  the  current  outcome  (unacceptable),  the  failed  heuristic  and  the  case  global 
and  local  features  to  find  another  possibly  applicable  revision  heuristic.  Invoking  CBR  with  these  indices 
retrieves  cases  that  have  failed  in  the  put  in  a  similar  manner  as  the  current  revision  This  use  of  CBR 
in  the  space  of  failures  is  a  domain-independent  method  of  failure  recovery  [Syc88,  Sim85],  and  allows  the 
problem  solver  to  access  past  solutions  to  the  failure.  If  the  result  is  acceptable,  then  CABINS  proceeds  to 
repair  another  activity. 

For  each  of  the  three  case  retrieval  situations  described  above,  CABINS  uses  a  k-Nearest  Neighbor  method 
(k-NN)  [DasSO]  for  cue  retrieval.  The  space  over  which  the  k-Nearest  Neighbor  calculation  is  done  is  the 
set  of  features  corresponding  to  each  of  the  three  retrieval  situations.  For  example,  for  case  retrieval  to 
select  a  repair  tactic,  k-NN  is  used  over  the  space  defined  by  the  values  of  global  and  local  features.  A  k-NN 
calculation  finds  the  k-nearest  neighbors,  where  k  is  some  constant  of  the  current  problem  from  the  training 
data  based  on  pre-determined  similarity  meuures  and,  in  its  simplest  form,  a  single  nearest  neighbor  is 
found  and  chosen  as  a  classification  result. 

We  selected  k-NN  instead  of  1-NN  for  the  following  reasons.  *  In  domains,  such  as  scheduling  that  do 
not  have  clear  predictive  features  due  to  lack  of  causal  structure,  there  can  be  many  matches  other  than  the 
nearest  match  that  can  potentially  contribute  to  accurate  classification  If  a  large  number  of  near  neighbor 
cases  are  of  the  same  category  (e.g.  suggesting  swap  as  the  tactic  to  be  applied),  a  higher  confidence  can 
be  given  to  the  classification  result  than  if  the  near  neighbors  are  of  many  different  categories  (e.g.  some 
suggesting  left  .shift  and  some  suggesting  swap).  For  example,  in  deciding  the  repair  tactic  to  be  applied  to 
the  current  problem,  suppose  that  we  have  five  nearest  neighbors.  Three  of  them  arc  left.shift  cases,  whose 
similarity  to  the  current  problem  is  0.9,  0.2  and  0.1  and  the  other  two  are  swap  cases,  whose  similarity  is 
0.8  and  0.75.  If  we  use  1-NN,  lefuhift  is  selected  as  a  repair  tactic  because  the  nearest  retrieved  case  (with 
similarity  0.9)  uses  leftjhift  as  a  successful  revision  tactic.  In  this  method,  the  occurrence  of  multiple  cases 
suggesting  a  different  classification  result  with  relatively  high  similarity  could  potentially  be  ignored.  We 
use  the  sum  of  the  similarity  in  k-nearest  neighbors  as  a  selection  criterion,  instead  of  using  the  frequency  of 
appearance  of  a  class  among  k-nearest  neighbors,  in  order  to  avoid  the  situation  where  dissimilar  cases  may 
have  an  undue  influence  on  the  classification  result  *.  In  the  previous  example,  swap  is  selected  as  a  repair 
tactic  by  CABINS  (since  its  total  similarity  is  1.55  vs.l  2  of  left-shift). 

The  similarity  between  a  case  and  the  current  problem  is  computed  in  CABINS  as  follows- 


1  in  the  current  implementation  of  CABINS,  k  ie  aet  to  S. 

sThis  method  has  been  luccenfnlly  applied  in  domains  without  clear  causal  structure,  such  as  English  word  pronunciation 
and  text  classification  in  [SW86,  CMSW92). 
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where  Salience'  is  the  salience  of  j-th  feature  of  i-th  case  in  the  case-base,  CascFcature J  is  the  value 
of  j-th  feature  of  i-th  case,  ProblemFeature ,  is  the  value  of  j-th  feature  in  the  current  problem,  EJ)evf  is 
the  standard  deviation  of  j-th  feature  value  of  all  cases  in  the  case-base,  and  Distance t  is  the  dissimilarity 
between  i-th  case  and  the  current  problem.  And  Similarity,  is  the  similarity  between  i-th  case  and  the 
current  problem. 

We  utilize  the  normalized  Euclidean  distance  to  measure  the  dissimilarity  between  a  case  and  a  problem. 
This  prevents  certain  features  from  dominating  distance  calculation  merely  because  they  have  large  numerical 
values. 


4.4.  Repair  by  CABINS 

Repair  of  a  schedule  is  performed  by  applying  the  repair  tactics  selected  in  each  repair  iteration  by  CBR. 

The  repair  tactics  currently  available  in  CABINS  are: 

ieft-slidc  I  try  to  move  focal-activity  on  the  same  resource  as  much  to  the  left  on  the  timeline  as  possible 
within  the  repair  time  horizon,  while  preserving  the  sequence  of  all  the  activities. 

left  .shift :  try  to  move  focal -activity  on  a  same  resource  as  much  to  the  left  on  the  timeline  as  possible 
within  the  repair  time  horizon  while  minimizing  the  disruptions. 

left-shiftantojilt :  try  to  move  foeal-activity  on  a  substitutable  resource  as  much  to  the  left  on  the 
timeline  as  possible  within  the  repair  lime  horizon  while  minimizing  the  disruptions. 

swap  i  swap  the  focal -activity  with  the  activity  on  its  left  on  the  same  resource  within  the  repair  time 
horizon  which  causes  the  least  disruptions 

i  swapjnto-alt  i  swap  the  focal-activity  with  activity  on  its  left  within  the  repair  time  horizon  which 

1  causes  the  least  disruptions  by  changing  the  resource  assignment  of  the  focal-activity  to  a  substitutable 

|  resource. 

give.up  :  give  up  a  further  mpair  of  the  current  focal-activity 

In  recent  work  we  hare  expanded  the  let  of  tactics  to  11  and  are  currently  performing  additional  exper¬ 
iments  with  them.  The  process  of  applying  a  repair  tactic  has  the  following  steps: 


1.  Determine  the  predictive  start  time  of  the  focal-activity  being  repaired  The  predictive  start  time  of 
an  activity  is  a  temporary  start  time  that  is  calculated  by  each  repair  tactic  as  a  desirable  start  time 
for  a  focal-activity.  The  ripple  effects  of  a  repair,  the  conflict  set,  consists  of  all  the  activities  that 
may  need  to  be  re-scheduled  due  to  constraint  violations  arising  from  moving  the  focal  -activity  to  the 
predictive  start  time.  Note  that  this  predictive  start  time  may  net  be  exactly  the  same  as  the  start 
time  that  will  result  from  execution  of  the  repair  (step  5  below). 

•  For  left-shift  or  left  .shift  jnto-alt,  the  “predictive*  start  time  is  the  start  time  that  minimizes 
capacity  over-allocation  as  a  result  of  moving  the  focal-activity  on  the  same  (or  substitutable) 
resource  within  the  focal-activity’s  repair  time  horizon. 
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•  For  swap  or  swap-into-alt,  the  “predictive"  start  time  is  the  start  time  that  causes  the  least 
amount  of  precedence  constraint  violations  on  the  same  (or  substitutable)  resource  within  the 
focal  .activity’s  repair  time  horizon. 

2.  Project  the  effects  of  moving  the  focai-aetivity  to  the  predictive  start  time  and  designated  resource 
This  is  done  by  performing  constraint  propagation  to  identify  capacity  constraint  violations. 

3.  Adjust  the  reservations  of  all  the  activities  in  the  conflict  set  by  simple  right-shifting  or  left-shifting 
so  that  all  conflicts  are  resolved. 

4  Change  the  bias  of  the  start  time  utility  function  (see  Fig.  2)  of  the  activities  in  the  conflict  set  in 
favor  of  start  times  calculated  in  step  3.  If  the  tactic  being  applied  involves  a  substitutable  resource, 
also  change  the  resource  utility-function  so  that  the  substitutable  resource  has  utility  higher  than 
the  resource  on  which  the  focal-activity  is  currently  scheduled.  Changing  the  utility  functions  biases 
selection  of  start  times  by  the  value  ordering  heuristic  (section  2  3)  in  favor  of  those  with  higher  utility 
values,  thus  reflecting  the  preferences  encoded  in  the  case  base. 

5.  Unschedule  the  focal  .activity  and  all  members  of  its  conflict  set  and  re-schedule  them  using  the  oppor¬ 
tunistic  constraint-directed  scheduler  with  ARR  variable  ordering,  GV  value  ordering  and  the  utility 
functions  defined  in  step  4 

6  Restore  the  start  time  utility-function  of  the  affected  activities  to  reflect  no  bias  for  the  next  repair 
iteration. 


The  above  process  results  in  a  conflict  free  revised  schedule.  The  effects  of  the  revision  are  calculated, 
and  CBR  is  invoked  with  the  effects  as  the  relevant  indices  to  evaluate  the  repair  outcome.  Note  that  an 
activity  Aj  can  be  moved  under  two  different  situations.  First,  Aj  can  be  moved  when  it  is  the  current 
focal-activity.  Second,  it  can  be  moved  when  it  is  in  the  conflict  set  of  another  focal-activity. 

Figure  6  gives  a  detailed  example  that  graphically  shows  how  the  local  repair  action  left-shift  can  be 
applied  In  this  simplified  example,  we  have  three  jobs  and  each  of  them  has  three  activities.  Suppose  the 
current  focal-activity  is  A’  and  leftshift  has  been  chosen  as  the  repair  tactic.  The  first  step  of  revision  is 
to  find  an  appropriate  start  time  for  activity  A|.  Left-shift  dictates  that  activity  Aj  should  be  starting  as 
soon  as  possible  within  the  given  repair  time  horizon,  Therefore,  the  utility  function  associated  with  Aj  that 
used  to  reflect  the  preference  for  starting  A|  as  late  as  possible  (indicated  in  the  figure  by  “Utility  function 
of  Aj  before  repair")  is  adjusted  accordingly.  In  the  figure,  the  new  utility  function  is  indicated  as  “Utility 
function  of  A]  after  adjustment” .  The  next  step  is  to  find  the  conflict  set  which  consists  of  all  affected 
activities  by  moving  Aj  to  the  left  The  members  of  thr  conflict  set  are  shown  in  the  figure.  The  utility 
function  of  each  activity  in  the  conflict  set  is  also  adjusted  to  reflect  these  changes.  In  the  figure,  we  show 
as  an  example  the  adjustment  of  the  utility  for  activity  Aj .  After  these  utility  functions  have  been  adjusted, 
the  focal-activity  and  the  activities  in  the  conflict  set  are  unscheduled  and  the  constraint-based  scheduler  is 
called  to  re-schedule  them.  The  resulting  repaired  schedule  is  shown  at  the  bottom  of  the  figure  6. 


4.5.  An  Example 

We  briefly  illustrate  the  repair  process  with  a  very  simple  example  schedule  to  be  repaired  shown  in  figure 
7  .  In  the  gantt  chart,  each  row  shows  assignments  of  activities  on  each  resource,  along  the  timeline,  and 
each  white  box  corresponds  to  an  assignment  of  an  activity.  The  number  inside  a  white  box  identifies  the 
job  which  the  activity  belongs  to.  For  example,  the  first  activity  on  resource2  is  the  first  activity  of  Job2, 
identified  in  our  text  as  Aj.  We  write  R,  to  indieate  the  ith  resource,  J;  to  identify  the  jth  job  and  AJ  to 
identify  the  kth  activity  of  job  n  The  example  has  ten  jobs  (di,.  ,  Jin)  and  each  job  has  five  activities 

with  the  linear  precedence  constraint,  (e  g.,  A"  BEFORE  AJ . AJ  BEFORE  AJ)  Resources  Ri  and  Rj, 

R  s  and  Rs  arc  substitutable;  resource  R\  is  a  bottleneck  Suppose  that  the  current  focal  job  is  Js  and  the 
current  focal-activity  is  A$.  The  indices  used  to  retrieve  the  similar  cases  from  the  case-base  are  calculated 
as  follows. 
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After  left-shift 
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Figure  6  Example  of  repair  tactic  application:  leftjshift 
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Figure  7:  Original  Schedule  Results 


1.  Global  features: 

Weighted  Tardiness:  In  this  particular  case,  the  weighted  tardiness  of  the  whole  schedule  is  468. 
Resource  Utilisation  Average:  This  feature  can  be  calculated  as  the  ratio  of  overall  utilisation 
of  resources  to  overall  availability  of  resources.  The  value  of  this  feature  is  0.544. 

Resource  Utilization  Deviation:  The  deviation  of  resource  utilizations  across  the  different  re¬ 
sources  is  equal  to  0  032. 

2.  Local  features: 

Waiting  Time:  This  feature  is  defined  as  the  time  elapsing  between  the  completion  of  the  preceding 
activity  (A*)  and  the  start  of  the  present  focal  activity  (A*).  In  our  case,  it  is  equal  to  1180-620  = 
560. 

The  prcdidivcshifi^ain  is  computed  in  CABINS  as  follows: 


prcdicliic  Mart  dime  -  currentMarldimc 
waitingdime 


X  repairabilily 


where  pndictivcMartdime  is  defined  in  section  4.4,  current  Mart  Jimt  and  wailing  dime  nre 
the  parameters  associated  with  focal  activity  We  heuristically  estimate  the  repairability  within 
the  given  repair  time  horizon  by  a  hyperbolic  tangent  function. 

For  our  example,  the  value  of  pndtcltveMift.jain  for  A*  is  0  705. 

Predictive  Ait  Shift  Gain'.  The  calculation  of  this  feature  is  very  similar  to  that  of  pndictivc.ihift.gain. 
In  this  ease,  since  the  required  resource  of  activity  A|  is  a  bottleneck  resource,  fU,  that  does  not 
have  any  substitutable  resources,  the  value  of  pniicttve.all.ihi]t.gain  is  0. 

Predictive  Swap  Gain!  To  calculate  pndiclivc.swap.gam,  CABINS  uses  the  same  formulas  as  for 
pndicUvc.th\ft.gam,  but  the  predicttse-sfert-tinie  is  calculated  differently.  (See  Section  4.4)  For 
this  example,  pndiciivcjwap.gam  is  0,96 

Predictive  Alt  Swap  Gain:  The  value  of  this  feature  is  0  since  A*  requires  the  bottleneck  resource 
Rt  which  does  not  have  substitutable  resources. 


Case  based  retrieval  is  performed  with  the  global  and  local  indices  It  turns  out  that  case-based  retrieval 
found  the  case  shown  in  Appendix  A  as  the  most  similar  and  thus  selected  map  as  the  repair  tactic  for  the 
focal-activity  A". 

To  apply  swap,  CARINS  calculates  the  activity  with  which  A®  will  be  swapped  To  do  this,  CABINS 
selects  the  activity  which,  if  swapped  with  Aj,  will  result  in  least  amount  of  precedence  constraint  violations 
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Figure  8:  Schedule  Result.  ..fter  Repair  on  AJ 

From  the  figure  7  we  can  see  that  actually  there  are  5  activities  swappable  with  A$  within  the  repair  horizon. 
These  activities  are:  Aj°,  A‘,A\,  A*  and  Aj.  At  first  glance,  it  may  appear  that  it  would  be  better  if  Aj  was 
swapped  with  Aj°  because  by  doing  so  A*  will  be  finished  as  early  as  possible.  However,  it  is  not  the  best 
choice  since  if  A$  is  swapped  with  Aj0,  it  will  cause  a  lot  of  downstream  ripple  effects  contrary  to  the  primary 
intention  of  beeping  repair  effects  as  localised  as  possible.  After  calculation  of  the  estimated  possible  effects, 
CABINS  decides  to  swap  A*  with  A{.  Job  Ji  has  weight  3  and  weighted  tardiness  3  x  (1370—  1320)  —  150. 
The  effect  of  applying  the  swap  tactic  it  that  A{  and  A\  are  unscheduled  on  ft,  and  A\  is  re-scheduled  to 
start  at  time  1090  (the  start  time  of  activity  A}  prior  to  the  swap)  Due  to  the  larger  duration  of  activity 
A*,  now  there  is  the  ripple  effect  of  a  precedence  constraint  violation  between  activity  Aj  and  its  successor 
activity  Aj  on  resource  Ri.  (In  general,  many  activities  could  be  affected  and  must  be  rescheduled  as 
described  in  section  4.4).  Constraint  propagation  discovers  this  constraint  conflict  and  shifts  activity  A{ 
further  to  the  right  on  resource  R3  resulting  in  the  repaired  schedule  shown  in  figure  8. 

Then,  the  effects  of  repairing  Aj  are  calculated,  CABINS  estimates  the  local  effects  on  the  focal-job 
Jt  and  calculates  global  effects  on  the  whole  schedule.  Machine  utilization  did  not  change  but  Js  had  an 
estimated  decrease  in  weighted  tardiness  of  180  time  units  and  an  estimated  decrease  in  WIP  of  200  units  *; 
Js  had  an  increase  in  weighted  tardiness  of  150  units  and  an  increase  in  WIP  of  750  units.  Global  weighted 
tardiness  decrease  is  180  -  150  =  30  and  global  WIP  increase  is  750.  CBR  is  invoked  using  the  these  effects 
and  applied  repair  tactic  as  indices  to  determine  whether  this  repair  outcome  is  acceptable.  If  there  are  more 
success  cases  than  failure  cases  in  the  retrieved  k-nearest  neighbors,  it  is  considered  that  the  effects  reflect 
tradeoffs  in  the  user’s  preferences  (in  this  example,  li'tle  weight  on  WIP)  and  the  outcome  is  considered 
acceptable.  If,  on  the  other  hand,  a  failure  case  is  retrieved,  then  the  outcome  is  considered  unacceptable, 
reflecting  the  user  preferences  for  minimization  of  weighted  tardiness  without  the  expense  of  increasing  WIP. 

In  th:s  example,  CBR  invocation  with  effects  as  indices  retrieves  as  the  closest  matching  case,  the  case 
shown  in  Appendix  B,  where  the  effects  match  the  effects  associated  with  the  swap  repair  tactic.  Therefore, 
the  outcome  is  deemed  "acceptable". 


5.  Evaluation  of  the  Approach 


We  conducted  a  set  of  experiments  to  test  the  following  hypotheses- 

1.  Our  approach  is  potentially  effective  in  capturing  user  preference?  and  optimization  tradeoffs  that  are 
difficult  to  model. 

2.  Our  approach  improves  schedule  quality  irrespective  of  method  of  initial  schedule  generation. 

decrease!  cannot  be  precisely  determined  until  the  last  scf*vi,y  of  h  f  1  is  repaired 
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3.  Out  approach  produces  high  quality  schedules  at  much  lower  computational  cost  as  compared  to 
simulated  annealing,  a  well-known  iterative  repair  method 

4.  Out  approach  is  suitable  as  a  reactive  scheduling  method  because  it  maintains  high  schedule  quality 
and  minimizes  disruptions  in  the  face  of  execution  time  failures. 

These  hypotheses  are  difficult  to  test  since,  due  to  the  subjective  and  ill-defined  nature  of  user  preferences, 
it  is  not  obvious  how  to  correlate  scheduling  results  with  the  captured  preferences  or  how  to  define  quality 
of  a  schedule  whose  evaluation  is  subjective. 

To  address  these  issues,  we  had  to  devise  a  method  to  test  the  hypotheses  in  a  consistent  manner.  To 
do  that,  it  is  necessary  to  know  the  optimization  criterion  that  would  be  implicit  in  the  case  base,  so  that 
the  experimental  results  can  be  evaluated.  In  the  experiments  reported  here,  we  used  two  different  explicit 
criteria  (weighted  tardiness;  WIP+weighted  tardiness)  to  reflect  the  user's  optimization  criteria  and  built  a 
rule-based  reasoncr  (RBR)  that  goes  through  a  trisl-and-error  repair  process  to  optimise  a  schedule.  Since 
the  RBR  was  constructed  not  to  select  the  same  repair  action  after  application  of  a  selected  repair  tactic 
was  evaluated  as  unacceptable,  it  could  go  through  all  the  repair  actions  before  giving  up  further  repair. 
Each  of  these  applications  of  a  repair  action  would  be  gathered  in  the  repair  history  of  the  case  for  the 
particular  activity  under  repair.  For  each  repair,  the  repair  effects  were  calculated  and,  on  this  basis,  since 
the  RBR  had  a  predefined  evaluation  objective,  it  could  evaluate  the  repair  outcome  consistently.  Thus,  we 
used  the  RBR  with  different  rules  each  time  to  generate  different  case  bases,  each  for  a  different  explicit 
optimization  objective.  Naturally,  an  objective,  though  known  to  the  RBR,  is  not  known  to  CABINS  and 
is  only  implicitly  and  indirectly  reflected  in  an  extensiona)  way  in  each  case  base.  By  designing  an  objective 
into  the  RBR  so  it  could  lie  reflected  in  the  corresponding  case  base,  we  got  an  experimental  baseline  against 
which  to  evaluate  the  schedules  generated  by  CABINS. 

We  evaluated  the  approach  on  a  benchmark  suite  of  job  shop  scheduling  problems  where  parameters, 
such  as  number  of  bottlenecks,  range  of  due  dates  and  activity  durations  were  varied  to  cover  a  broad  range 
of  parallel  machine  job  shop  scheduling  problem  instances.  In  particular,  the  benchmark  problems  have  the 
following  structure:  each  problem  has  10  orders  of  5  activities  each.  Each  order  has  a  linear  process  routing 
specifying  a  sequence  where  each  order  must  visit  bottleneck  resources  after  a  fixed  number  of  activities, 
so  as  to  increase  resource  contention  and  make  the  problem  tighter.  Two  parameters  were  used  to  cover 
different  scheduling  conditions:  a  range  parameter,  RG.  controlled  the  distribution  of  order  due  dates  and 
release  dates,  and  a  bottleneck  parameter,  BK,  controlled  the  number  of  bottleneck  resources.  To  ensure 
that  we  had  not  unintentionally  hardwired  knowledge  of  the  problem  into  the  solution  strategies,  we  used  a 
problem  generator  function  that  embodied  the  overall  problem  structure  described  above  to  generate  parallel 
job  shop  scheduling  instances  where  the  problem  parameters  were  varied  in  controlled  ways.  In  particular, 
six  groups  of  10  problems  each  were  randomly  generated  by  considering  three  different  values  of  the  range 
parameter  (static,  moderate,  dynamic),  and  two  values  of  the  bottleneck  configuration  (1  and  2  bottleneck 
problems).  The  slack  was  adjus'ed  as  a  function  of  the  range  and  bottleneck  parameters  to  keep  demand 
for  bottleneck  resources  close  to  100%  over  the  major  part  of  each  problem,  Durations  for  activities  in  each 
order  were  also  randomly  generated. 

Generating  problem  instances  "in  the  neighborhood’1  of  a  problem  by  controlled  variation  of  problem 
parameters  is  a  well-accepted  method  in  Operations  Research  and  knowledge-based  scheduling  communities 
for  evaluating  the  performance  of  scheduling  methods  (e.g.,  [Sad91,  SC93])  The  problem  instances,  although 
randomly  generated,  shared  features  of  problem  structure  (e.g  ,  each  problem  has  5  machines,  of  which  1 
and  2  machines  are  bottlenecks,  end  substitutable  machines  exist  for  the  non  bottleneck  machines  etc),  and 
CBR  can  exploit  the  captured  regularities  in  the  structure  of  the  problems  for  transfer  to  later  problem 
solving,  it  is  interesting  to  note  that  this  transfer  carries  over  even  if  the  number  of  orders  is  varied  (see 
Table  5). 

The  benchmark  problems  are  variations  of  the  problems  originally  reported  in  [Sad9I]  and  used  as  a 
benchmark  by  a  number  of  researchers  (e.g.  (Mus93.  TS93)).  Our  problem  sets  are,  however,  different  in  two 
respects  (a)  we  allow  substitutable  resources  for  non-bottleneck  resources,  thus  solving  the  parallel  machine 
rather  than  the  simple  job  shop  scheduling  problem,  and  (b)  the  due  dates  of  orders  in  our  problems  are 
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tighter  by  20  percent  than  in  the  original  problems. 

A  cross-validation  method  was  used  to  evaluate  the  capabilities  of  CABIN'S.  Each  problem  set  in  each 
class  was  divided  in  half  The  overall  training  sample,  consisting  of  30  problems,  each  of  which  has  50 
activities,  was  repaired  by  RBR  to  gather  cases  As  has  been  explained  in  the  section  on  case  acquisition 
(section  4.2),  a  case  is  acquired  for  each  activity  that  is  the  current  focal  .activity  (irrespective  of  the  number 
of  tactics  available  or  number  of  tactics  used  in  the  activity's  repair).  Of  course,  an  activity  (and  consequently 
a  job)  may  be  repaired  more  than  once  during  an  overall  repair  cycle,  since  it  is  repaired  as  a  focal  activity 
but  also  as  an  activity  in  the  conflict  set  of  another  focal.aetivity,  and  thus  must  be  moved.  Allowing  each 
activity  to  be  a  focal  activity  once  for  each  problem  would  give  a  maximum  of  30X50  =  1 ,500  cases  for  each 
training  sample  (for  each  different  experimental  optimisation  objective)  In  practice,  some  of  the  activities 
did  not  become  focal -activities  to  be  repaired  because  they  did  not  have  enough  upstream  alack  (see  section 
4),  so  that  for  each  training  sample,  CABINS  was  trained  with  approximately  1,100  cases.  These  cases  were 
then  used  for  case-based  repair  of  the  validation  problems  (the  other  30  problems).  We  repeated  the  above 
process  by  interchanging  the  training  and  the  test  sets  Reported  result*  are  for  the  validation  problem 
sets.  Since  it  is  not  possible  to  theoretically  predict  the  bounds  of  repair  or  the  global  optimum,  in  the 
experiments,  CABINS  was  allowed  to  run  for  three  overall  repair  cycles. 


5.1.  Preference  Acquisition 

To  test  the  hypothesis  that  CABIN'S  could  acquire  user  preferences,  we  constructed  through  RBR  two  case 
bases,  the  first  to  reflect  the  user's  preference  for  repairs  that  minimise  weighted  tardiness  and  the  second 
to  reflect  the  more  complex  criterion  of  minimizing  the  combination  of  weighted  tardiness  and  WIP.  The 
cases  constituted  the  only  source  of  knowledge  for  CABINS.  In  other  words,  there  was  no  objective  given  to 
CABINS  explicitly.  The  case-bases  were  used  both  as  a  source  of  suitable  repairs,  and  also  as  a  source  of 
advice  regarding  repair  evaluation. 

Graphs  in  Fig.  9  show  the  comparison  of  the  performance  by  CABINS  using  “weighted  tardiness"  case 
base  (labeled  in  the  graphs  as  CABINS(WT))  and  the  performance  by  CABINS  using  the  “weighted  tar¬ 
diness  and  WIP”  case  base  (labeled  in  the  graphs  as  CABINS(WT+WIP)).  From  the  results,  we  observe 
that  CABINS(W'T)  generated  higher  quality  schedules  with  respect  to  minimising  weighted  tardiness  than 
CABINS(WT+WIP)  in  all  six  problem  classes.  Conversely,  CABINS(WT+VVIP)  generated  higher  quality 
schedules  with  respect  to  WIP,  and  weighted  tardiness  plus  WIP  than  CABINS(WT)  in  the  all  problem 
classes.  In  a  nutshell,  CABINS(WT)  tries  to  optimise  a  schedule  only  in  terms  of  weighted  tardiness  and 
neglects  WIP,  but  CABIN'S(WT+W1P)  takes  into  account  the  tradeoffs  between  weighted  tardiness  and 
WIP  in  schedule  repair.  These  results  indicate  that  CABINS  can  acquire  different  and  subjective  user 
preferences  on  the  tradeoffs  of  diverse  objectives  in  scheduling  from  the  cases.  Thus  in  our  approach,  un¬ 
like  traditional  heuristic  scheduling  approaches  [FreS2,  MP93],  it  is  not  necessary  to  devise  a  particular 
heuristic  to  suit  the  optimization  criterion.  Only  the  case-base  must  be  changed  for  different  optimisation 
objectives.  In  addition,  unlike  traditional  search-based  scheduling  approaches  such  as  braneb-and-bound, 
dynamic  programming,  tabu  search,  simulated  annealing  and  so  on,  our  approach  doesn't  require  an  explic¬ 
itly  represented  objective  function.  CABINS  has  the  potential  for  inducing  more  complicated  form  of  user’s 
objectives  (e  g.  allowing  handling  of  exceptional  situations)  from  the  cases.  It  is  true  that  user’s  objectives 
could  be  elicited  by  intensely  interviewing  domain  experts  and  represented  in  the  form  of  rules  as  we  have 
done  in  constructing  RBR  modules  to  gather  esses  in  the  experiments.  But,  (1)  rule-based  knowledge  ac¬ 
quisition  is  extremely  laborious  [PreW]  and  (2)  a  scheduling  problem  is  so  ill  structured  that  even  a  domain 
expert  cannot  have  a  sufficient  knowledge  for  making  a  good  schedule  efficiently  (KLSF91),  Nevertheless, 
the  CBRrbased  methodology  of  CABIN'S  can  induce  efficient  control  model  from  the  cases  obtained  through 
the  applications  of  insufficient  rules. 

In  another  set  of  experiments  with  objective  WIP+WT,  tve  used  RBR  itself  to  repair  the  set  of  test 
problems.  Table  1  shows  that  repair  by  CABINS  is  about  40%  more  efficient  than  repair  by  RBR  and  it 
improves  the  quality  of  schedules  by  about  12%  more  than  repair  by  RBR.  A  potential  explanation  for  these 
results  is  that,  as  described  in  section  4.3,  CABINS  can  effectively  utilise  failure  information  stored  in  the 
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cases  (Refer  to  [MS94]  for  more  details  and  some  experimental  results ) 


5.2.  Predictive  and  Reactive  Scheduling 

We  evaluated  CABINS  against  other  scheduling  methods  using  standard  criteria  (e  g  [OST88,  ZDGSOj) 
for  evaluating  schedule  revision  quality.  These  criteria  are  also  appropriate  for  planning.  These  criteria 
were:  (a)  Attendance  to  scheduling  objectives'  what  it  the  quality  of  the  revision  with  respect  to  the 
desired  optimization  criteria?  (b)  Amount  of  disruption:  how  many  changes  to  the  original  schedule  are 
made?  (c)  Efficiency  of  revision:  how  quick  is  the  revision  process?  In  particular,  can  the  revision  process 
be  responsive  to  schedule  execution  in  the  sense  of  allowing  execution  to  proceed  as  rapidly  as  possible? 
Although  we  subscribe  to  the  view  that  both  schedule  generation  and  schedule  repair  can  be  viewed  as  an 
iterative  repair  process,  for  ease  of  readability,  we  have  described  our  experiments  in  two  separate  subsections 
5.2.1  and  5  2.2. 

Schedule  quality  and  efficiency  is  important  in  both  predictive  schedule  generation  and  reactive  schedule 
management.  Responsiveness  of  the  schedule  revision  process  is  crucial  during  handling  of  schedule  execution 
failures  (and  opportunities)  to  patch  up  the  schedule  quickly  and  allow  execution  to  proceed.  Minimising 
schedule  disruption  is  most  important  during  reactive  management  of  a  schedule.  Once  a  schedule  starts 
executing,  it  is  important  to  preserve  continuity  of  domain  activity,  since  there  could  be  substantial  cost  in 
having  to  attend  to  discontinuities  introduced  by  reactive  schedule  revision  (e.g.  set-up  costs  when  resource 
sssignment9  have  been  changed).  These  criteria  must  be  balanced  and  traded  off  against  each  other. 

The  results  show  that  in  predictive  schedule  generation,  tire  methodology  improves  the  quality  of  sched¬ 
ules  generated  by  a  variety  of  scheduling  methods  and  also  generates  schedules  of  higher  quality  along  a 
variety  of  optimization  objectives  with  lower  processing  cost  as  compared  to  simulated  annealing,  a  well- 
known  iterative  optimization  method  [JAMS89,  ZDG90,  LA  192].  In  recovering  from  execution  time  failures, 
•he  approach  (1)  attends  to  schedule  quality  both  in  terms  of  optimization  objectives,  and  disruption,  and 
(2)  is  responsive  in  that  it  allows  continuation  of  execution  without  delays  in  response  to  execution  failures. 


5.2.1.  Predictive  Schedule  Repair 

In  predictive  schedule  repair,  the  primary  objective  in  our  experiments  was  to  optimize  schedule  quality  at  a 
low  computational  cost.  To  investigate  out  experimental  hypotheses,  we  compared  CABINS  with  Simulated 
Annealing.  Simulated  Annealing  (SA)  is  a  well  known  iterative  improvement  approach  to  combinatorial 
optimisation  problem*,  which  is  reported  to  be  able  to  yield  solutions  of  better  quality  at  the  cost  of  larger 
computational  efforts  in  a  number  of  combinatorial  optimization  domains,  such  as  computer-aided  design 
of  integrated  circuit,  image  processing  and  neural  network  theory  ((JAMS91,  LAL92]).  SA  has  also  been 
spphed  to  job-shop  scheduling  domain  for  the  maksspan  objective  and  it  reported  ([LAL92])  to  have  a 
potential  of  finding  shorter  makesptns  than  the  state-of-the-art  tailored  heuristic,  e.g.  shifting  bottleneck 
procedure  ([ABZ88]). 

The  details  of  the  our  SA  implementation  ate  given  as  follows: 

1.  Generate  an  initial  schedule 

2.  Select  an  activity  randomly 

3.  Unless  all  the  available  repair  actions  have  been  tried,  do  the  following- 

(a)  Select  a  repair  action  among  the  remaining  un-tried  repair  tactics, 

(b)  Apply  the  chosen  repair  tactic  to  the  activity  under  repair; 

(c)  Evaluate  the  resulting  repaired  schedule  with  respect  to  the  explicit  objective  (WIP+WT) 
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Table  2:  Repair  by  CABINS  and  SA  baaed  on  Different  Methods  of  Initial  Schedule  Generation 
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1220.0 
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(d)  If  the  resulting  schedule  is  better  than  the  schedule  before  repair  in  terms  of  the  objective,  then 
the  revision  procedure  goes  on  to  repair  next  randomly-chosen  activity; 

Otherwise  the  revision  procedure  goes  on  to  repair  next  randomly-chosen  activity  with  probability 
cxp(-A/Tcmp),  in  which  A  is  defined  as  the  difference  of  schedule  evaluations  after  repair  and 
before  repair. 

The  temperature  Temp  is  updated  (decreased  by  a  fixed  percentage  every  time)  when  a  fixed  number 
(currently  250)  of  repair  actions  have  been  applied  and  the  revision  procedure  will  be  terminated  if  a  pre¬ 
set  maximum  computational  effort  has  been  leached.  We  tan  each  experiments  5  times  and  reported  the 
best  results  among  chese  5  separate  runs  (since  SA  incorporates  a  probabilistic  factor,  the  results  are  not 
necessarily  the  same  across  the  different  experimental  runs). 

In  order  to  test  the  generality  of  the  approach,  we  repeated  the  same  set  of  experiments  4  times,  where 
each  time  the  initial  (seed)  schedule  was  generated  using  a  set  of  well  regarded  dispatch  heuristics  and  a 
constraint-based  scheduler  (CBS)  The  dispatch  rules  selected  to  generate  the  initial  schedule  are  widely  used 
in  practical  job  shop  scheduling  problems,  namely  the  Earliest  Due  Date  (EDD)  rule,  the  Weighted  Shortest 
Processing  Time  (WSPT)  rule  and  the  WSPT  with  order  time  urgency  factor  (R&M)  rule.  These  heuristics 
have  been  reported  to  be  particularly  good  at  reducing  tardiness  under  different  scheduling  conditions 
[MP93].  We  also  used  the  constrained-based  scheduler  (CBS),  which  uses  AR.R  variable  ordering  heuristic 
and  GV  value  ordering  heuristic  with  pre-determined  biased  start  time  utility-functions  (see  section  2.3). 

In  our  experiments,  the  user’s  objective  function  was  assumed  to  be  minimizing  weighted  linear  combi¬ 
nation  of  work-in-process  inventory  (WIP)  plus  weighted  tardiness.  This  is  a  multi-objective  function  that 
is  difficult  to  optimise  heuristically.  WIP  and  weighted  tardiness  are  not  always  compatible  with  each  other. 
There  are  situations  where  WIP  is  reduced,  but  weighted  tardiness  increases. 

Table  2  presents  the  average  results  of  all  €0  problems  in  the  benchmark  Based  on  the  results,  we  make  a 
variety  of  observations.  Fi-st,  CABINS  improved  the  initial  schedule  across  all  scheduling  methods  according 
to  the  objectives.  It  should  be  noted  that  these  dispatch  heuristics  have  been  extensively  used  in  Operations 
Research  experimentation  with  very  good  results  |Bak74,  MRV84).  The  initial  schedules  generated  by  the 
dispatch  heuristics  can  be  considered  as  local  minima,  in  the  sense  that  they  cannot  be  easily  improved. 
For  example,  these  initial  schedules  are  very  tight,  in  that  there  is  no  on-purpose  machine  idleness.  We 
conjecture  that  it  would  be  more  difficult  to  improve  an  initial  schedule  with  higher  quality  For  example, 
it  would  he  more  difficult  to  improve  an  ”ni:M''-generated  schedule  than  an  "EDD” -generated  one.  The 
experimental  results  support  this  conjecture  (EDD-generaled  schedule  has  been  improved  by  25  9  percent 
and  R&M-generated  schedule  has  been  improved  by  a  12  6  percent)  Second,  we  observe  that  the  better 
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the  quality  of  the  initial  schedule,  the  better  the  quality  of  the  repaired  result  Third,  CABINS  generated 
schedules  of  comparable  quality  but  was  on  the  average  4-5  times  more  efficient  than  simulated  annealing. 
It  seems  that  the  contextual  information  captured  in  the  CABINS  case  base  and  the  system’s  use  of  failure 
information  in  the  repair  history  is  effectively  used  to  guide  the  search  and  prune  unpromising  paths  thus 
malting  CABINS  much  more  efficient  than  the  random  search  of  simulated  annealing. 
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WT+W1P 

CPU  Sec. 
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81.2 

Repair  by  SA 
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«TT:yi 

3142.4 

323.3 

Table  3:  Repair  by  CABINS  on  Randomly  Generated  Initial  Schedules 

To  further  investigate  CABIXS’s  behavior  vis  a  vis  initial  schedule  generation  method,  we  again  used 
training  and  test  sets  of  5  resources  and  10  problems.  The  initial  schedule  for  each  problem  is  randomly 
generated  from  scratch.  To  do  this,  we  took  into  account  the  precedence  constraints  and  resource  constraints 
(disregarding  due  date  constraints)  so  generation  of  an  executable  schedule  was  guaranteed.  As  expected,  the 
qualities  of  these  initial  schedules  are  very  low  (compared  to  the  ones  generated  by  the  dispatch  heuristics 
and  CBS)  I>om  the  table  3  we  can  see  that  CABINS  also  performs  well  on  these  randomly  generated 
initial  schedules.  The  behavior  of  CABINS  with  regard  to  the  method  of  initial  schedule  generation  confirms 
intuitions  in  the  Operations  Research  community  (e.g.  [MP93])  that  the  higher  the  quality  of  the  initial 
solution,  the  better  the  repaired  solution.  This  is  also  consistent  with  the  behaviot  of  other  repair-based 
methods,  for  example  the  behavior  of  simulated  annealing  in  our  experiments,  and  also  the  min-conflict 
heuristic's  behavior  for  constraint  satisfaction  problems  (MJPL92). 

Other  interesting  experimental  results  we  got  so  far  arc 

•  Evaluation  of  revision  control  model  learning 

Wc  conducted  another  set  of  experiments  to  ascertain  the  effectiveness  of  case-based  learning  of  the 
control  model  for  selecting  the  repair  actions.  The  results  without  learning  were  obtained  by  random, 
not  case-based,  selection  and  application  of  the  same  repair  tactics  for  activity  repair.  The  results 
showed  that  repair  did  not  improve  schedule  quality  of  approximately  80%  of  the  example  problems 

•  Evaluation  of  scalability 

To  test  the  scalability  of  our  approach  we  generated  an  additional  set  of  60  problems  each  with  20 
jobs,  each  of  which  uses  5  resources.  Usually,  in  real  operating  environments,  the  factory  configuration 
(e  g.  number  and  type  of  machines)  is  likely  to  remain  relatively  the  same  for  reasonably  long  periods. 
The  number  of  orders,  however,  is  very  likely  to  fluctuate  due  to  varied  customer  demands  and  other 
economic  factors.  Based  on  these  assumptions,  in  our  experimentation,  we  focused  on  varying  number 
of  jobs  rather  than  number  of  resources.  The  20- job  problems  were  generated  from  the  same  problem 
generator  function  by  varying  the  same  parameters  (as  for  the  set  of  10-job  problems)  in  controlled 
ways.  The  knowledge  acquisition  method  was  the  aame  as  for  the  10-job  problems,  i.e.  RBR  was  used 
to  acquire  a  training  case  base  with  30  problems  each  of  which  has  20  jobs  and  5  resources.  We  also 
used  cross  validation  approach.  The  pattern  of  results  was  the  same  as  for  the  first  set  of  60  problems. 
The  results  are  shown  in  Thble  4, 

•  Evaluation  of  knowledge  transferability 

In  order  to  test  generalization  issues  in  case-based  learning  and  transferability  of  acquired  knowledge, 
(1)  we  collected  the  cases  through  solving  the  5  resources  and  10  jobs  benchmark  problems  (using 
RBR).  and  (2)  we  used  the  case-base  collected  in  Step  1  to  solve  the  5  resources  and  20  jobs  problems. 
The  results  are  shown  in  Table  5.  We  see  that  although  the  results  we  got  based  on  5  nsourct  and  SO 
jobs  case-base  are  better  (reported  in  table  4),  CABINS  still  performs  very  well  on  the  bigger  problems 
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'Able  4.  Repair  by  CABIN'S  on  5  resource.;  and  2C  orders  Problems 
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T&bU  5:  Repair  on  5  X  20  Problems  using  Case-Base  collected  from  o  X  10  problems 


using  the  original  5  resource  and  10  jobs  case-base.  We  also  see  that  the  pattern  of  CABINS  behavior, 
i.e.  improving  schedule  quality  independent  of  initial  schedule  generation  still  bolds. 
fYoin  the  knowledge  acquisition  and  practical  point  of  view,  the  results  are  quite  encouraging.  They 
show  that  CABINS  has  potential  for  application  in  operational  factory  environments,  since  knowledge 
transferability  will  alleviate  the  knowledge  acquisition  burden  without  much  affecting  overall  system 
performance  and  quality  of  scheduling  results. 


5.2.2.  Repair  in  Response  to  Unpredictable  Execution  Events 

Reactive  schedule  repair  involves  (1)  recognition  of  the  conflicts  that  are  introduced  in  the  schedule  as 
a  result  of  an  unexpected  and  uncontrollable  change  in  the  execution  environment,  (2)  propagation  of  the 
conflicts,  and  (3)  selection  and  application  of  &  repair  action.  Before  we  present  and  discuss  the  experimental 
hypotheses,  evaluation  criteria  and  results,  we  present  the  reactive  repair  steps  taken  by  CABINS. 

The  first  step  in  reactive  repair  is  the  recognition  of  conflicts  introduced  in  the  schedule  as  a  result  of 
unexpected  events  in  the  execution  environment.  In  general,  there  are  two  types  of  conflicts  that  can  be 
recognized: 


Temporal  conflicts:  These  are  conflicts  reflecting  inconsistencies  between  the  scheduled  and  actual  start 
and  end  times  of  activities 

Resource  conflicts;  These  are  conflicts  reflecting  inconsistencies  in  the  resource  capacity  currently  avail¬ 
able  and  the  capacity  required  for  processing  activities 
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In  the  second  step,  the  effects  of  the  introduced  conflicts  are  propagated  downstream  (forward  in  time) 
from  the  point  in  time  where  the  unexpected  event  happened  (right-shifting)  This  involves  undoing  the 
reservations  that  become  inconsistent  as  a  result  of  the  unexpected  event  and  propagating  their  effects  to 
determine  the  consequences  (ripple  effects)  of  the  unexpected  event  for  the  rest  of  the  schedule.  The  result 
of  this  step  is  a  feasible  schedule  but  typically  of  much  worse  quality  than  the  predictive  schedule  before  the 
occurrence  of  the  deleterious  unexpected  event. 

In  the  third  step,  CABINS  is  used  to  repair  the  suboptimal  schedule  that  resulted  in  the  second  step. 
The  mechanisms  that  CABINS  uses  in  reactive  repair  are  exactly  the  same  used  for  predictive  optimization 
(except,  of  course,  that  no  attempt  is  made  to  repair  activities  that  have  being  already  executed  before  the 
unexpected  event  happened).  If  the  unexpected  event  is  loss  of  capacity  (e.g.  a  machine  breakdown),  the 
activity  that  was  being  processed  on  the  resource  at  the  time  of  breakdown  must  also  be  re-scheduled. 

We  illustrate  the  repair  process  by  an  example.  Figure  10  shows  a  predictive  schedule  for  one  of  the 
problems  that  were  used  for  experimentation  with  predictive  schedule  optimization  (see  section  5.2. 1).  In 
particular,  it  is  one  of  the  two-bottleneck  problems  with  static  start  time  for  all  jobs  In  this  schedule,  the 
weighted  tardiness  is  240  units. 

After  computing  the  predictive  schedule,  a  machine  breakdown  is  created  in  the  middle  of  the  schedule. 
The  broken  machine,  M,  is  the  busiest  non-bottleneck  machine.  The  breakdown  was  timed  to  occur  at  the 
first  20%  of  total  execution  time  so  as  to  increase  its  deleterious  effects  on  the  rest  of  the  schedule  The 
estimated  duration  of  the  breakdown  was  10  times  the  average  duration  of  the  activities  in  the  problem  M 
is  assumed  available  for  processing  at  the  end  time  of  the  breakdown. 

The  effects  of  the  breakdown  are  propagated  downstream  (forward  in  time)  In  particular,  the  activities 
that  were  scheduled  on  the  broken  machine  M  and  whose  scheduled  reservations  overlapped  with  the  time 
interval  of  the  breakdown,  are  unscheduled  and  re-scheduled  in  the  same  sequence  on  M  after  the  end  time 
of  the  breakdown  (this  has  been  called  right-shifting  in  [OST88]).  Right-shifting  of  these  activities  on  M 
typically  results  in  constraint  conflicts  of  related  activities  that  are  fixed  by  the  constraint  propagation 
mechanisms  in  CABINS  so  that  a  feasible  but  worse  schedule  results.  Figure  11  shows  the  schedule  resulting 
from  the  machine  breakdown  and  its  propagated  effects  The  weighted  tardiness  of  this  schedule  is  4500, 
a  more  than  ten-fold  worsening  of  quality.  Delsying  schedule  execution  til)  M  is  fixed,  which  is  equivalent 
to  right-shifting,  is  clearly  not  an  option  in  practice.  It  is  of  the  utmost  importance  that  the  schedule  be 
repaired  to  enable  execution  continuity. 

CABINS  is  applied  to  repair  the  schedule  of  figure  1 1 .  Because  of  the  big  delays  that  arise  as  a  consequence 
of  capacity  loss,  we  assume  optimisation  of  weighted  tardiness  as  the  repair  objective.  Figure  12  shows  the 
schedule  resulting  after  repair  by  CABINS.  Weighted  tardiness  has  been  decreased  ten-fold  (from  4500  to 
450). 

In  general,  there  are  three  responses  (repair  strategies)  that  a  planning/scheduling  system  can  have  to  the 
occurrence  of  unexpected  events  during  execution.  First,  do  not  attempt  any  repair.  This  strategy  results 
in  not  taking  advantage  of  any  opportunities  (e.g.,  activities  finishing  earlier  than  their  scheduled  end  time, 
additional  resources  becoming  available)  or  incurring  execution  delays  entailed  by  deleterious  events  (e.g., 
partial  or  total  loss  of  resource  capacity,  activities  finishing  later  than  their  scheduled  times).  This  strategy 
is  obviously  suboptimal.  A  second  repair  strategy  could  be  to  throw  away  the  rest  of  the  plan/schedule 
and  re-plan/re-schedule  from  the  point  of  the  occurrence  of  the  unexpected  event  It  has  been  speculated 
in  the  literature  (e.g  ,  [OST88,  ZDG80))  that  such  strategy  may  efficiently  produce  high  quality  schedules 
but  may  increase  schedule  disruption  (though  no  measure  of  disruption  was  given  in  previous  work)  A 
third  repair  strategy  could  be  incremental  revision  of  the  existing  schedule.  It  has  been  argued  in  the 
literature  that  an  incremental  repair  process  that  achieves  efficient  generation  of  high  quality  schedules  and 
also  allows  continuation  of  execution  while  minimizing  schedule  disruption  would  be  the  most  desirable.  To 
date  no  experiinental  evidence  has  been  provided  (a)  in  favor  of  incremental  schedule  repair  as  opposed  to 
re-scheduling,  or  (b)  exhibiting  an  incremental  repair  approach  that  performs  well  on  all  the  above  repair 
objective  simultaneously 
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Figure  10:  Schedule  Result  before  Machine  Breakdown 


Figure  11:  Schedule  Result  after  Machine  Breakdown 
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Figure  12:  Schedule  Result  after  Reactive  Repair 
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Table  6:  Reactive  repair  vs  Re-schedultng 


We  demonstrate  CABINS’*  reactive  capability  with  respect  to  execution  time  failures,  aince  they  are  the 
ones  that  typically  happen  and  against  which  a  scheduling  system  must  guard  In  the  set  of  experiments  «e 
performed,  CABIN'S  was  used  to  repair  a  predictive  schedule  in  response  to  unexpected  capacity  loss.  CBS 
was  used  for  re-scheduling  Our  experimental  results  demonstrate  that  the  incremental  repair  methodology 
of  CABINS  is  superior  to  re-scheduling  in  performing  reactive  schedule  repairs  in  response  to  execution 
futures  along  all  the  desirable  evaluation  criteria. 

We  measured  disruption  with  respect  to  three  criteria: 

1.  Difference  of  start  times  between  the  repaired  schedule  and  the  original  predictive  schedule  (before 
occurrence  of  the  unexpected  capacity  loss) 

2.  Difference  in  resource  assignment  of  activities  in  the  repaired  versus  the  original  schedule 

3.  Difference  in  sequencing  of  activities  on  a  resource  in  the  repaired  versus  the  engine!  schedule 

These  changes  between  the  repaired  and  the  original  schedule  qualify  as  measures  of  schedule  disruption  since 
they  could  cause  changes  (with  attendant  costs)  in  resource  set-up  activities,  process  routing,  nnd  expected 
job  finish  times.  For  example,  in  a  manufacturing  environment,  changes  in  start  times  may  cause  changes 
in  plans  for  product  warehousing,  material  preparation  and  product  shipment  plans;  change  of  resource 
assignments  may  change  product  routings  in  the  factory  floor  resulting  in  the  need  to  change  programs 
of  material  handling  equipment  (such  as  automated  guided  vehicles);  changes  in  activity  sequencing  on 
a  machine  may  cause  changes  in  machine  set-ups  and  worker  assignments.  Such  changes  cause  serious 
difficulties  in  the  smooth  continuation  of  schedule  execution  on  a  factory  floor.  Obviously,  the  degree  of 
severity  of  such  changes  depends  on  the  nature  of  the  manufacturing  process  and  the  factory  floor  layout. 
Therefore,  a  unified  measure  of  disruption  of  a  schedule  is  hard  to  formulate. 

We  compare  the  performance  of  reactive  repair  against  CBS  re-schcduling  in  the  two  different  machine 
breakdown  scenarios,  each  of  which  has  ten  sets  of  problems.  In  the  first  experiment,  a  machine  breakdown, 
whose  duration  is  10  times  the  average  activity  duration,  is  simulated  on  the  two-bottleneck  resource  prob¬ 
lems,  and  in  the  second  experiment,  a  similar  machine  breakdown  is  simulated  on  the  set  of  one-bottleneck 
problems. 

Table  6  shows  the  average  results  across  all  experiments. 

The  results  show  that  in  terms  of  disruption  and  quality  CABINS  outperformed  re-scheduling  by  CBS. 
However,  CABINS’s  efficiency  is  much  worse  than  CBS.  In  some  problems,  such  as  problem  1  for  example, 
CABINS  spends  as  much  as  40  times  more  time  as  CBS. 

However,  upon  further  examination,  this  result  is  misleading.  The  reason  is  the  rapid  and  monotonie 
repair  behavior  of  CABINS.  As  shown  in  figure  13,  for  example,  CABINS  achieved  better  result  quality 
than  CBS  at  the  time  point  when  CBS  finished  re-scheduling.  From  figure  13  we  see  that  after  9.3  seconds, 
CABINS  has  achieved  a  weighted  tardiness  of  1430  units  compared  to  1560  units  achieved  by  re-scheduling 
in  the  same  time  period  (9  3  secs).  Since,  in  contrast  to  the  re-scheduling  method  which  does  not  pro¬ 
vide  incremental  schedule  feasibility,  CABINS’  incremental  reactive  repair  results  in  a  feasible  (executable) 
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schedule  after  every  repair  iteraiion,  if  the  repair  process  is  stopped  after  9.3  secs,  the  schedule  produced  by 
CABINS  can  he  executed  and  is  of  higher  quality  than  the  one  produced  by  CBS  re-scheduling  during  the 
same  time  period.  This  behavior  was  consistency  exhibited  in  all  experiments. 

System  responsiveness  in  reactive  contexts  is  of  great  concern.  To  see  whether  the  results  of  13  are  robust 
across  different  breakdown  scenarios,  we  repeated  the  experiments  with  four  different  variations  of  duration 
of  machine  breakdown.  In  each  experiment,  the  breakdown  duration  was  4,  6,  8,  and  10  times  the  average 
activity  duration  Figure  14  shows  those  results.  The  graph  shows  that  reactive  repair  is  very  efficient  at 
first  anil  then  saturates  until  no  further  improvement  is  possible.  This  characteristic  of  CABINS'  repair 
process  is  very  suitable  for  reactive  repair  since  it  allows  continuation  of  execution  with  minimal  delay  {most 
of  the  schedule  quality  loss  is  repaired  very  rapidly). 


5.3.  How  Many  Cases  Are  “Enough”? 
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Figure  15-  Effect  of  case-base  sires  in  quality  and  efficiency 


The  graphs  in  figure  15  compare  the  performance  of  CABINS  with  different  sized  case-bases.  The  results 
were  obtained  bated  on  CABINS  with  WT+WJP  type  of  ease-bases.  A  case  of  approximately  4,500  cases 
was  generated  by  RBR  This  was  done  by  allowing  3  overall  repair  cycles  for  a  training  act  of  30  problems 
each  of  which  has  50  activities  To  get  the  case  bases  of  different  sizes,  an  appropriate  number  of  cases 
for  each  situation  was  randomly  selected  and  deleted  from  the  approximately  4,500  size  case  bate.  This 
method  of  generating  a  new  case  base  by  random  deletion  of  cases  from  a  bigger  case  base  is  similar  to  the 
ablation  study  performed  in  [Bar89j.  The  initial  schedule  generation  method  was  CBS.  From  the  viewpoint 
of  knowledge  acquisition,  an  interesting  question  it  when  knowledge  acquisition  can  be  terminated  because 
sufficient  knowledge  has  been  acquired  to  enable  high  quality  performance  of  a  knowledge  based  system.  For 
case-based  knowledge  acquisition,  this  question  becomes  how  many  cases  would  be  enough  for  knowledge 
capture  and  reuse  and  for  guaranteeing  overall  satisfactory  performance  Unfortunately,  it  is  very  difficult  to 
answer  this  question  in  general  due  to  the  ill-structuredness  of  the  scheduling  problem  and  the  approximate 
nature  of  CBR  (since  no  causal  model  is  available).  We  believe,  however,  that  there  exists  some  appropriate 
size  of  the  case-base  which  will  give  us  relatively  satisfactory  results  in  terms  of  schedule  quality  without 
excessive  ovethead  for  case  acquisition  or  case  retrieval  from  the  case  base. 

Our  experimental  results  (figure  15)  support  this  hypothesis  as  follows: 

1.  The  larger  the  number  of  cases,  the  better  the  schedule  quality.  However,  the  marginal  payoff  from  the 
increase  in  case  base  size  decreases.  This  can  be  explained  partially  by  the  fact  that  some  number  of 
cases  (say,  1000  cases)  capture  well  characteristics  of  the  problem  space,  and  additional  1000  new  cases 
may  give  much  redundant  information.  When  the  size  of  case-base  is  relatively  small,  every  time  new 
cases  are  acquired,  we  may  get  information  about  a  different  part  of  the  problem  space  which  results 
in  higher  quality  improvement. 

2.  In  terms  of  efficiency  of  the  system,  we  observe  (torn  the  graphs  that  the  case-base  with  1000  cases 
might  be  the  optimal  choice  Actually,  both  in  terms  of  CPU  time  and  quality  improvement,  the 
ease-base  with  1000  cases  obviously  outperforms  the  case-base  with  500  cases.  Moreover,  in  terms  of 
schedule  quality  improvement,  case  bases  with  more  than  1000  cases  do  not  seem  to  provide  payoff 
proportional  to  the  case  base  size  increase 
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5.4.  Discussion 


The  experimental  results  show  that  the  CBR-based  repair  method  not  only  has  the  potential  to  capture 
different  user  optimisation  preferences  but  also  performs  well  in  terms  of  producing  schedules  of  high  quality 
as  compared  with  other  constructive  scheduling  methods.  As  compared  with  simulated  annealing,  another 
repair-based  method,  CBR-based  repair  produces  schedules  of  comparable  quality  with  substantial  compu¬ 
tational  savings.  In  addition,  CBR-based  repair  exhibits  desirable  anytime  characteristics  and  outperforms 
re-scheduling  by  a  constructive  constraint-based  method  in  terms  of  minimizing  disruption  and  maintaining 
high  schedule  quality. 

In  this  section ,  we  will  attempt  to  answer  the  question  "what  makes  the  approach  powerful'  ?  We  believe 
the  power  of  the  approach  stems  from  the  following  four  reasons.  First,  as  has  been  pointed  out  by  others  (c.g. 
[MJPL92]),  revision-based  approaches  by  malting  available  a  complete  assignment  (a  complete  schedule  for 
our  domain)  provide  more  information  that  can  guide  search  as  compared  with  constructive  methods  where 
only  a  partial  assignment  is  available.  Our  CBR-based  revision  method  captures  such  relevant  information 
in  global  case  features  and  exploits  it  is  contextual  information  during  case  retrieval.  Second,  although  job 
shop  schedule  optimization  belongs  to  the  category  of 'hard'  KP-complete  problems,  the  case  features  were 
able  to  capture  some  important  domain  regularities,  such  at  repair  flexibility.  This  was  complemented  by 
keeping  information  about  failed  applications  of  revisions  in  the  repair  case  history  and  also  keeping  failed 
esses  in  the  case  memory.  These  failures  were  exploited  by  CBR  to  prune  unpromising  paths  in  the  search 
space  in  future  similar  situations  Third,  experimental  results  and  discussion  presented  in  section  5.3  support 
the  hypothesis  that  the  cases  CABINS  acquired  and  used  in  the  reported  experiments  seem  to  cover  the 
solution  space  in  a  fairly  evenly  distributed  fashion,  thus  allowing  CBR-based  repair  to  take  advantage  of  this 
coverage.  Since,  however,  we  cannot  conjecture  whether  good  quality  solutions  are  evenly  distributed  in  the 
search  space  as  a  whole,  backtrack  search,  for  example,  could  be  potentially  disadvantaged  if  good  solutions 
are  'bunched  up"  in  particular  parts  of  the  search  space  [MJPL92,  Lan92],  whereas  dispatch  heuristics  are 
too  myopic  to  take  advantage  of  promising  search  paths. 

Finally,  we  believe  that  some  of  the  regularities  in  the  structure  of  the  experimental  problems  were 
captured  in  cases  during  the  training  phase  and  this  information  was  transferable  to  solve  the  test  problems. 
Moreover,  this  information  teems  to  transfer  also  across  problem  size  as  the  the  results  in  Table  5  indicate. 
The  table  shows  that  the  cases  acquired  during  training  with  a  set  of  10- job  problems  were  effective  in  solving 
test  problems  with  20  jobs  The  question  then  arises  to  what  extent  the  information  captured  in  cases  from 
one  set  of  problems  can  transfer  to  job  shop  optimization  problems  with  different  problem  structure.  This 
question,  albeit  of  great  theoretical  and  practical  importance,  is  very  difficult  to  answer  in  a  theoretical 
way.  In  contrast  to  other  NP-complete  problems  (e.g.  graph-coloring,  satisfiability,  traveling  salesman)  for 
which  insightful  analysis  has  been  performed  (e.g.  [MR92,  CKT91))  as  to  their  structure  and  properties  that 
characterize  'easy"  or  "hard"  problem  instances,  similar  eharseterization  of  job  shop  schedule  optimization 
problems  is  currently  an  open  research  problem  (e.g,]CKT91,  Bak74)).  Due  to  the  tight  constraint  inter¬ 
dependencies  in  job  shop  optimization,  it  it  not  known  what  constitutes  "problem  structure”,  i.e.  what 
features  of  a  problem  make  it  difficult  or  easy  to  solve,  or  make  one  problem  substantially  similar  or  different 
from  another.  It  is  for  this  reason  that,  except  for  some  simple  optimisation  objectives,  such  as  minimise 
flowtime  for  one-machine  problems  where  it  has  been  proven  that  the  WSPT  heuristic  finds  the  optimal 
solution,  it  is  currently  impossible  to  theoretically  prove  schedule  optimality  for  a  particular  technique  It 
is  only  after  some  proposed  problem  has  defied  solution  by  extensive  experimentation  by  many  researchers 
that  it  is  understood  ipio  facto  to  be  difficult  (ABZ88,  Bak74] .  Most  importantly,  even  if  there  were  good 
approaches  to  characterize  problem  structure  in  job  shop  optimization,  with  explicit  optimization  criteria, 
this  would  not  help  with  our  analysis  since  CABINS  does  not  have  an  explicit  objective  function,  but  instead 
aims  at  capturing  implicitly  context-dependent  user  preferences. 


33 


ADA289383 


6.  Related  Work 


Our  work  shares  the  same  motivations  and  goals  with  the  work  in  [MBS88]  where  the  motivations  for 
interactive  user  manipulation  of  schedules  is  presented.  In  that  work,  the  system  monitors  the  user's  manip¬ 
ulation  of  a  schedule,  requesting  the  reasons  for  each  revision  that  is  made.  This  information  is  then  used 
to  augment/refine  the  system’s  knowledge.  The  approach  seems  promising  but  has  not  been  experimentally 
tested. 

Our  approach  is  rooted  on  concepts  and  mechanisms  of  a  long  line  of  research  in  constraint-directed 
scheduling  [Fox83,  SOL+86,  Sad91].  In  that  work,  schedules  are  generated  by  incrementally  constructing 
and  merging  partial  schedules.  That  work  has  extensively  investigated  various  properties  and  aspects  of  this 
scheduling  methodology  and  has  proposed  sophisticated  procedures  and  techniques  for  constraint-directed 
scheduling.  Although  this  research  tradition  has  come  to  view  scheduling  as  an  opportunistic  repair  process, 
it  has  operated  under  static  design  assumptions  (eg.  deterministic  application  of  variable  and  value  ordering 
heuristics  in  [Sad91],  or  statically  determined  control  level  model  for  application  of  repair  actions  [OST88]). 
Our  approach  advances  the  state  of  the  art  by  learning  to  dynamically  adapt  the  focusing  mechanism  of  the 
search  procedure  and  by  adapting  the  repair  model  according  to  current  problem  solving  circumstances  and 
user  preferences  and  tradeoffs. 

Our  approach,  generates  schedules  oy  repair  based  scheduling  in  the  space  of  complete  schedules.  In  this 
respect  it  is  similar  to  [ZDG90,  ZDDD93,  MJPL90,  BC91J.  In  [ZDG90,  ZDDD93)  simulated  annealing  has 
been  used  to  perform  iterative  repair.  Knowledge  in  the  form  of  constraint  types  and  evaluation  criteria  has 
been  added  to  the  basic  simulated  annealing  framework  and  has  been  shown  to  improve  convergence  speed 
[ZDDD93],  [ZDDD92]  has  studied  the  tradeoff  of  minimising  perturbations  vs.  speed  of  convergence  to  a 
conflict  free  schedule  and  vs.  schedule  quality  measured  in  terms  of  number  of  violated  resource  constraints 
In  [MJPL90,  MJPL92]  the  min-conflict  heuristic,  a  repair  heuristic  that  chooses  the  repair  that  minimizes 
the  number  of  conflicts  that  result  from  a  one-step  lookahead  has  been  investigated  and  its  performance 
analysed.  Though  the  heuristic  has  been  shown  to  be  powerful  for  solving  the  N-queens  problem,  it  has  been 
shown  insdequate  for  some  types  of  job  shop  scheduling  constraint  satisfaction  problems  [Mut93]  when  the 
initial  assignment  is  random  This  is  because  nun-conflicts  relies  on  a  good  initial  assignment  [MJPL92J. 
The  CBR-based  repair  of  CABINS,  on  the  other  hand  has  been  shown  experimentally  to  improve  schedule 
quality  irrespective  of  initial  schedule  generation  method,  although  the  percent  improvement  and  the  quality 
of  the  final  repaired  schedule  varies  In  [BC91]  schedule  modifications  are  procedurally  encoded.  Small 
snapshots  of  the  scheduling  process,  called  chronologies,  are  used  to  focus  the  search  by  using  information 
gained  incrementally  during  the  scheduling  process  to  locate,  classify  and  resolve  bottlenecks.  In  [ZDB+92] 
plausible  explanation  based  learning  (PEBL)  has  been  applied  to  learn  search  control  rules  to  increase  search 
efficiency  in  scheduling  tasks  for  NASA  Space  Shuttle  payload  and  ground  processing.  PEBL  enables  a  system 
to  generalize  a  given  target  concept  (e  g.  chronic  resource  contention)  over  a  distribution  of  examples.  The 
cost  function  is  to  minimize  the  number  of  remaining  conflicts  in  the  schedule.  Unlike  all  the  above  systems, 
CABINS  doesn’t  have  any  explicit  objectives  to  optimize,  but  applies  case-based  learning  techniques  to 
acquire  user  optimization  preferences  from  the  records  of  user’s  repair  decisions  and  optimizes  schedules 
based  on  the  acquired  objectives. 

The  tepaic-based  scheduling  methods  considered  here  are  related  to  the  repair-based  methods  that  have 
been  previously  used  in  case-based  planning  systems  (e  g.  [Vel92,  KH92,  Ham89j),  Previous  ease-based  sys¬ 
tems  for  incremental  solution  revision  have  been  motivated  primarily  by  concerns  of  computational  efficiency, 
preserving  plan  correctness  rather  than  improving  plan  quality,  and  have  assumed  the  existence  of  a  strong 
domain  model  to  get  information  as  to  plan  correctness.  For  example,  CHEF  [Ham89]  assumes  the  existence 
of  a  model-based  simulator  to  evaluate  a  derived  plan  and  detect  a  plan  failure  and  uses  well-studied  domain 
rules  for  selecting  repairs.  Research  by  (KH92,  Vel92]  are  baaed  on  the  hypothesis  that  the  plan  built  by 
their  planner  is  causally  and  teleologically  correct,  and  use  CBR  to  find  the  satisfying  plan  efficiently. 

CABINS  as  a  knowledge  acquisition  system  is  also  related  to  previous  case-based  knowledge  acquisition 
systems  (eg  Protos  [Bar89])  These  approaches  usually  require  causal  explanations  from  an  expert  teacher 
to  acquire  domain  knowledge.  In  CBR-based  schedule  repair  embodied  in  CABINS,  neither  the  user  nor  the 
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program  are  assumed  to  possess  causal  domain  knowledge.  The  user  cannot  give  a  solid  explanation  as  to 
her/his  selection  of  repair  action,  because  s/he  cannot  predict  the  effects  of  the  selected  action  on  the  plan 
caused  by  tight  interactions.  The  user’s  expertise  lies  in  the  ability  to  perform  consistent  evaluation  of  the 
results  of  problem  solving  and  impart  to  the  program  cases  of  problem  solving  experiences  and  histories  of 
evaluation  tradeoffs 


7,  Conclusions  and  future  Work 


In  this  paper,  we  advocate  a  framework  for  knowledge  acquisition  and  iterative  repair  for  schedule  opti¬ 
misation.  The  approach  utilises  CBR-bssed  mechanisms  for  recording  user  preferences,  repair  tactics  and 
explanations,  and  constraint-based  scheduling  for  application  of  the  selected  repair  tactics.  The  approach 
is  predicated  on  (a)  the  existence  of  a  set  of  schedule  repair  tactics,  each  of  which  operates  with  respect  to 
a  particular  local  view  of  the  problem  and  offers  selective  advantages  for  improving  schedule  quality,  and 
(b)  on  capturing  and  re-using  user  scheduling  preferences  and  judgmenta.  The  capability  of  acquiring  user 
optimisation  preferences  is  important  in  domains  without  strong  domain  models  because  usually  explicitly 
expressed  objectives  are  unavailable  Even  if  they  were  available,  new  optimisation  heuristics  would  need  to 
be  developed,  evaluated  and  implemented  complicating  the  design  and  maintenance  of  the  system.  CABINS 
provides  a  framework  for  alleviating  these  problems.  Our  experimental  results  show  the  potential  of  the 
approach  to  capture  and  effectively  utilise  user  scheduling  preference*  that  were  not  present  in  the  schedul¬ 
ing  model.  The  results  indicate  that  different  scheduling  objectives  implicitly  reflected  in  the  case  base 
differentially  biss  the  schedule  repair  procedure.  Further  experimental  results  show  that  for  well  defined 
objectives  reflected  in  the  case  base,  CABINS  produces  schedule*  with  higher  quality  as  compared  with 
other  repair-based  scheduling  methods,  such  as  simulated  annealing  In  addition,  CABINS  is  robust  in  the 
sense  that  it  always  improved  the  quality  of  a  schedule  regardless  of  which  method  was  used  for  generating 
the  seed  schedule.  It  seems  that  the  effort  expended  to  capture  a  large  number  of  cases  can  be  amortired 
by  future  repeated  use  of  the  esse  bsse  to  get  high  quality  schedules  efficiently.  More  importantly,  CABINS 
can  acquire  the  cases  through  user  interaction  during  the  process  of  solution  improvement  without  imposing 
undue  overhead  on  the  user.  We  believe  that  CABINS  has  the  potential  for  accommodating  acquisition 
of  user  preferences  that  change  over  time.  Future  work  will  investigate  this  issue  and  issues  of  automating 
hierarchical  abstraction  of  the  repair  process,  and  dealing  with  more  complex  objectives  and  larger  problems. 
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APPENDIX  Ai  Case  Instance 


T.cass  < 

nan*  *  "«p_0_0.8:ordsr5-l:l:aetlvity6_2"; 
slots  *  ( 

Slot  { 
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feature  *  oeighted. tardiness; 
value  •  470.000000: 
salience  =  1.000000; 

>i 

Slot  < 

feature  *  resouree.utilization.average; 
value  =  0.780000; 
salience  =  1.000000; 

>; 

Slot  i 

feature  =  resource.utilization.davlation; 
value  =  0.0403740; 
salience  «  1.000000; 

>; 

); 

Sl.slots  *  ( 

Slot  { 

feature  «  salting. tine; 
value  «  680. 000000;- 
salience  *  0.333; 

>; 

Slot  { 

feature  »  predietive.shift.gain; 
value  •  0.806000; 
salience  >  0.667; 

}; 

Slot  < 

feature  «  predictive.alt.ehift.vlp.gain; 
value  •  0.106000; 
eelience  ■  0.333; 

>; 

Slot  < 

feature  •  predictive.svap.gain; 
value  •  0.803000; 
salience  *  0.667;. 

}; 

Slot  { 

feature  *  pradictlve.alt_svap.galu; 
value  «  0; 
salience  «  0.333; 

}; 


solutions  «  ( 

Solution  < 
tactlcs.type  •  SWAP; 
effects  •  < 

Effect  { 

elfeet.type  *  VEIBHTED.TAMIIESS ; 
salience  «  0.667; 
doaain  3  ''uhole.  schedule"; 
previous. value  a  470.000000; 
current. value  •  380.000000; 
gain  •  90.000000; 

}; 
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Eifact  { 

aifect.typ*  =  RESOURCE. UTILIZATIOR. AVERAGE ; 

<tli«nc<  =  0.667; 

domain  •  "?hol«_ich*dul*H ; 

pravioua.valu*  *  0.789000; 

cnrrant.value  «  0.789000; 

gain  a  0; 

>; 


Eifact  < 

aifaet.tjrp*  «=  RESOURCE.UTIUZATIO*J)EVIAIIO*; 

lalianca  >  0,667; 

domain  =  "nhola.achadula" ; 

pravioua.valua  <  0.0403769; 

currant. vain*  *  0.0403749; 

gain  =  0; 

>;, 

EHact  < 

aiiact.typ*  «  IHPROCESS.ISVESTORY; 
aalianc*  =  0.667; 
domain  =  "uhole.aciitdula"; 
pravioua.valua  ■  2240.000000 
currant. vain*  •  2250.000000; 
gain  «  -10.000000; 

>i 

EHact  { 

alfact.tjrpo  ■  INPROCESS.IN VENTORY ; 

■alaenca  *  0.333; 
domain  •  "Job7"; 
pravioua.valua  *  290.000000; 
currant.valu*  <  310.000000;, 
gain  =  -20.000000; 

>; 


)i 

raault  *  ACCEPTABLE; 

h 

); 

) 


APPENDIX  B:  Case  Used  for  Evaluation 


T.casa  { 
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sum  9  "exp_2_0_4:order7-l:l:activity7_2"; 
slots  9  ( 

Slot  < 

feature  9  veighted.tardiness; 
value  9  670.000000; 
salience  9  1.000000; 

>; 

Slot  { 

feature  9  resource.utilization.average ; 
value  9  0.682000; 
salience  9  1.000000; 

>; 

Slot  { 

feature  9  resource.utilization.deviation; 
value  9  0.074000; 
salience  9  1.000000; 

>; 

); 

Sl.slots  9  ( 

Slot  { 

feature  9  uaiting.time; 
value  9  280.000000; 
salience  9  0.333; 

>; 

Slot  { 

feature  9  predict ivs.ihift.gain; 
value  9  0.406000;. 
salience  ■  0.687; 

>; 

Slot  { 

feature  9  predictive_alt.shlft.uip.galn; 
value  9  0.306000; 
salience  •  0.333;. 

};■ 

Slot  < 

feature  9  predictive.svap.gain;. 
value  9  0.103000; 
salience  9  0.667;. 

>; 

Slot  { 

feature  •  predictive.alt.s»ap.galn;. 
value  9  0.304000;, 
salience  9  0.333;- 

>;■ 

);, 


solutions  9  ( 

Solution  { 

tacties.type  9  LEFT.SHIFT,, 
effects  9  ( 

Effect  < 

effect.typj  •  WEI0HTED.T1MIKSS; 
salience  9  0.667; 
donain  -  "whole. schedule"; 
previous.value  9  670.000000; 
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current,  value  «  930.000000; 
gain  =  '260.000000;. 

>; 


Effect  { 

effect .type  a  RESOURCE.UTILIZATIOI. AVERAGE ; 

•Alienee  -  0.667; 

domain  *  "uhole.schedule1'; 

previous, value  *  0.662000; 

current .value  c  0.682000; 

gain  »  0; 


Effect  { 

effect.type  *  RESOURCE.UTILIZATIOH.EEVIATIOI ; 

salience  *  0.667; 

domain  -  "uhole.schedule"; 

previous. value  *  0.074000; 

current .value  *  0.074000; 

gain  «  0; 

}; 

Effect  { 

effect.type  ■=  IRPROCESS.IBVESTORY  ;• 

•alienee  =  0.667; 
domain  *  "uhole.schedule"; 
previon».value  *  1940.000000 
current. value  «  1990 . 000000 ; 
gain  ■  -  EO. 000000; 

); 


);. 

result  ■=  UR  ACCEPT ABLE;- 

>; 

Solution  { 
tactics. type  a  5VAP ; 
effects  a  ( 

Effect  { 

effect.type  »  VEIGETEO.rAROIBESS;. 
salience  *  0.667; 
domain  «  "uhole.schedule" ; 
previous .value  •  670.000000; 
current .value  ■  600,000000; 
gain  •  70.000000; 

);, 

Effect  { 

effect.type  a  RESOURCE.UTILIZATIOI!.  AVERAGE ; 

salience  =  0.667; 

domain  a  "uhole.schedule"; 

previous. value  a  0.662000;, 

current. value  a  o . 662000 ; 

gain  •  0; 

};: 
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Effect  { 

affact.type  =  RESOUSCB.UTILIZATIOILDEVIATIOIl; 

salience  =  0.667; 

domain  =  "«hole_ichedule''; 

pr«viom_v»lu«  »  0.07*000; 

currant.value  *  0.074000; 

gain  =  0; 

>; 


Effect  < 

effect.type  -  I6PROCESS.IIVEITOSY; 
•alienee  •  0.667; 
domain  a  "»hole_»ehedule" ; 
previous.value  a  2480.000000; 
currant  .value  =  3180.000000;. 
gain  *  -700.000000; 

>; 

Eilact  { 

effect .type  a  WEIGHTED .TARDIHESS; 

aalianca  •  0.333; 

domain  «  "jot>7"; 

pretrioua.valua  a  790; 

eurrent.valua  =  210; 

gain  »  880;. 

>;• 

Eilact  < 

effect.type  »  I«PR0CESS_IIVESTCRY; 

aalianca  *  0.333; 

domain  a  "job9"; 

previous.value  =  290; 

eurrent.valua  =  410; 

gain  •  -120; 

>;■. 

);, 

raault  a  ACCEPTABLE; 

>; 

H 

} 
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